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Even the natives have difficulty mastering this peculiar vocabulary. 


—The Golden Bough, Sir James George Frazer 
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Asymmetric decryption of ciphertext Y using A’s private key PR, 
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Asymmetric encryption of plaintext X using A’s private key PR, 


Asymmetric encryption of plaintext X using A’s public key PU, 


Secret key 


Private key of user A 


Public key of user A 
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Absolute value of a 


xX concatenated with y 
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Bitwise exclusive-OR of x and y for multiple-bit variables 


The largest integer less than or equal to x 


The element x is contained in the set S. 


The integer A corresponds to the sequence of integers 
(44, a), ..., Ax) 


PREFACE 


“The tie, if I might suggest it, sir, a shade more tightly knotted. One aims at the 
perfect butterfly effect. If you will permit me —” 

“What does it matter, Jeeves, at a time like this? Do you realize that 
Mr. Little’s domestic happiness is hanging in the scale?” 

“There is no time, sir, at which ties do not matter.” 


—Very Good, Jeeves! P.G. Wodehouse 


In this age of universal electronic connectivity, of viruses and hackers, of electronic eaves- 
dropping and electronic fraud, there is indeed no time at which security does not matter. Two 
trends have come together to make the topic of this book of vital interest. First, the explosive 
growth in computer systems and their interconnections via networks has increased the 
dependence of both organizations and individuals on the information stored and communi- 
cated using these systems. This, in turn, has led to a heightened awareness of the need to 
protect data and resources from disclosure, to guarantee the authenticity of data and 
messages, and to protect systems from network-based attacks. Second, the disciplines of 
cryptography and network security have matured, leading to the development of practical, 
readily available applications to enforce network security. 


OBJECTIVES 


It is the purpose of this book to provide a practical survey of both the principles and practice 
of cryptography and network security. In the first part of the book, the basic issues to be 
addressed by a network security capability are explored by providing a tutorial and survey of 
cryptography and network security technology. The latter part of the book deals with the 
practice of network security: practical applications that have been implemented and are in 
use to provide network security. 

The subject, and therefore this book, draws on a variety of disciplines. In particular, it is 
impossible to appreciate the significance of some of the techniques discussed in this book 
without a basic understanding of number theory and some results from probability theory. 
Nevertheless, an attempt has been made to make the book self-contained. The book presents 
not only the basic mathematical results that are needed but provides the reader with an 
intuitive understanding of those results. Such background material is introduced as needed. 
This approach helps to motivate the material that is introduced, and the author considers 
this preferable to simply presenting all of the mathematical material in a lump at the begin- 
ning of the book. 


INTENDED AUDIENCE 


The book is intended for both academic and a professional audiences. As a textbook, it is 
intended as a one-semester undergraduate course in cryptography and network security for 
computer science, computer engineering, and electrical engineering majors. It covers the 
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material in IAS2 Security Mechanisms, a core area in the Information Technology body of 
knowledge; NET4 Security, another core area in the Information Technology body of knowl- 
edge; and IT311, Cryptography, an advanced course; these subject areas are part of the 
ACM/IEEE Computer Society Computing Curricula 2005. 

The book also serves as a basic reference volume and is suitable for self-study. 


PLAN OF THE BOOK 


The book is divided into seven parts (see Chapter 0 for an overview): 


e Symmetric Ciphers 

e Asymmetric Ciphers 

e Cryptographic Data Integrity Algorithms 
e Mutual Trust 

e Network and Internet Security 

e System Security 

e Legal and Ethical Issues 


The book includes a number of pedagogic features, including the use of the computer 
algebra system Sage and numerous figures and tables to clarify the discussions. Each chapter 
includes a list of key words, review questions, homework problems, suggestions for further 
reading, and recommended Web sites. The book also includes an extensive glossary, a list 
of frequently used acronyms, and a bibliography. In addition, a test bank is available to 
instructors. 


ONLINE DOCUMENTS FOR STUDENTS 


For this new edition, a tremendous amount of original supporting material has been made 
available online, in the following categories. 


e Online chapters: To limit the size and cost of the book, four chapters of the book 
are provided in PDF format. This includes three chapters on computer security and 
one on legal and ethical issues. The chapters are listed in this book’s table of 
contents. 

e Online appendices: There are numerous interesting topics that support material 
found in the text but whose inclusion is not warranted in the printed text. A total of 
fifteen online appendices cover these topics for the interested student. The appen- 
dices are listed in this book’s table of contents. 

e Homework problems and solutions: To aid the student in understanding the material, 
a separate set of homework problems with solutions are available. These enable the 
students to test their understanding of the text. 

e Key papers: Twenty-four papers from the professional literature, many hard to find, 
are provided for further reading. 

e Supporting documents: A variety of other useful documents are referenced in the text 
and provided online. 

e Sage code: The Sage code from the examples in Appendix B in case the student wants 
to play around with the examples. 


PREFACE XVIii 


Purchasing this textbook now grants the reader six months of access to this online 
material. See the access card bound into the front of this book for details. 


INSTRUCTIONAL SUPPORT MATERIALS 


To support instructors, the following materials are provided: 


e Solutions Manual: Solutions to end-of-chapter Review Questions and Problems. 

e Projects Manual: Suggested project assignments for all of the project categories listed 
below. 

e PowerPoint Slides: A set of slides covering all chapters, suitable for use in lecturing. 

e PDF Files: Reproductions of all figures and tables from the book. 

e Test Bank: A chapter-by-chapter set of questions. 


All of these support materials are available at the Instructor Resource Center 
(IRC) for this textbook, which can be reached via personhighered.com/stallings or by 
clicking on the button labeled “Book Info and More Instructor Resources” at this book’s 
Web Site WilliamStallings.com/Crypto/CryptoSe.html. To gain access to the IRC, 
please contact your local Prentice Hall sales representative via pearsonhighered.com/ 
educator/replocator/requestSalesRep.page or call Prentice Hall Faculty Services at 
1-800-526-0485. 


INTERNET SERVICES FOR INSTRUCTORS AND STUDENTS 


There is a Web site for this book that provides support for students and instructors. The site 
includes links to other relevant sites, transparency masters of figures and tables in the book 
in PDF (Adobe Acrobat) format, and PowerPoint slides. The Web page is at 
WilliamStallings.com/Crypto/CryptoSe.html. For more information, see Chapter 0. 

New to this edition is a set of homework problems with solutions available at this Web 
site. Students can enhance their understanding of the material by working out the solutions 
to these problems and then checking their answers. 

An Internet mailing list has been set up so that instructors using this book can 
exchange information, suggestions, and questions with each other and with the author. As 
soon as typos or other errors are discovered, an errata list for this book will be available at 
WilliamStallings.com. In addition, the Computer Science Student Resource site at 
WilliamStallings.com/StudentSupport.html provides documents, information, and useful 
links for computer science students and professionals. 


PROJECTS AND OTHER STUDENT EXERCISES 


For many instructors, an important component of a cryptography or security course is a pro- 
ject or set of projects by which the student gets hands-on experience to reinforce concepts 
from the text. This book provides an unparalleled degree of support, including a projects 
component in the course. The IRC not only includes guidance on how to assign and structure 
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the projects, but it also includes a set of project assignments that covers a broad range of 
topics from the text. 

e Sage Projects: Described in the next section. 

e Hacking Project: This exercise is designed to illuminate the key issues in intrusion 
detection and prevention. 

e Block Cipher Projects: This is a lab that explores the operation of the AES encryption 
algorithm by tracing its execution, computing one round by hand, and then exploring 
the various block cipher modes of use. The lab also covers DES. In both cases, an 
online Java applet is used (or can be downloaded) to execute AES or DES. 

e Lab Exercises: A series of projects that involve programming and experimenting with 
concepts from the book. 

e Research Projects: A series of research assignments that instruct the student to 
research a particular topic on the Internet and write a report. 

e Programming Projects: A series of programming projects that cover a broad range of 
topics and that can be implemented in any suitable language on any platform. 
Practical Security Assessments: A set of exercises to examine current infrastructure 
and practices of an existing organization. 

e Writing Assignments: A set of suggested writing assignments organized by chapter. 
e Reading/Report Assignments: A list of papers in the literature — one for each 
chapter — that can be assigned for the student to read and then write a short report. 


See Appendix A for details. 


THE SAGE COMPUTER ALGEBRA SYSTEM 


One of the most important new features for this edition is the use of Sage for cryptographic 
examples and homework assignments. Sage is an open-source, multiplatform, freeware pack- 
age that implements a very powerful, flexible, and easily learned mathematics and computer 
algebra system. Unlike competing systems (such as Mathematica, Maple, and MATLAB), 
there are no licensing agreements or fees involved. Thus, Sage can be made available on 
computers and networks at school, and students can individually download the software to 
their own personal computers for use at home. Another advantage of using Sage is that 
students learn a powerful, flexible tool that can be used for virtually any mathematical 
application, not just cryptography. 

The use of Sage can make a significant difference to the teaching of the mathematics 
of cryptographic algorithms. This book provides a large number of examples of the use of 
Sage covering many cryptographic concepts in Appendix B. 

Appendix C lists exercises in each of these topic areas to enable the student to gain 
hands-on experience with cryptographic algorithms. This appendix is available to instruc- 
tors at the IRC for this book. Appendix C includes a section on how to download and get 
started with Sage, a section on programming with Sage, and includes exercises that can be 
assigned to students in the following categories: 


e Chapter 2 — Classical Encryption: Affine ciphers and the Hill cipher. 
e Chapter 3 — Block Ciphers And The Data Encryption Standard: Exercises based on 
SDES. 
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e Chapter 4 — Basic Concepts In Number Theory And Finite Fields: Euclidean and 
extended Euclidean algorithms, polynomial arithmetic, and GF(24). 

e Chapter 5 — Advanced Encryption Standard: Exercise based on SAES. 

e Chapter 6 — Pseudorandom Number Generation And Stream Ciphers: Blum Blum 
Shub, linear congruential generator, and ANSI X9.17 PRNG. 

e Chapter 8 — Number Theory: Euler’s Totient function, Miller Rabin, factoring, modular 
exponentiation, discrete logarithm, and Chinese remainder theorem. 

e Chapter 9 — Public-Key Cryptography And RSA: RSA encrypt/decrypt and signing. 

e Chapter 10 — Other Public-Key Cryptosystems: Diffie-Hellman, elliptic curve 

e Chapter 11 — Cryptographic Hash Functions: Number-theoretic hash function. 

Chapter 13 — Digital Signatures: DSA. 


WHAT?’S NEW IN THE FIFTH EDITION 


The changes for this new edition of Cryptography and Network Security are more substantial 
and comprehensive than those for any previous revision. 

In the three years since the fourth edition of this book was published, the field has seen 
continued innovations and improvements. In this new edition, I try to capture these changes 
while maintaining a broad and comprehensive coverage of the entire field. To begin this 
process of revision, the fourth edition was extensively reviewed by a number of professors 
who teach the subject. In addition, a number of professionals working in the field reviewed 
individual chapters. The result is that, in many places, the narrative has been clarified and 
tightened, and illustrations have been improved. Also, a large number of new “field-tested” 
problems have been added. 

One obvious change to the book is a revision in the organization, which makes for a 
clearer presentation of related topics. There is a new Part Three, which pulls together all of 
the material on cryptographic algorithms for data integrity, including cryptographic hash 
functions, message authentication codes, and digital signatures. The material on key manage- 
ment and exchange, previously distributed in several places in the book, is now organized in 
a single chapter, as is the material on user authentication. 

Beyond these refinements to improve pedagogy and user friendliness, there have been 
major substantive changes throughout the book. Highlights include: 


e Euclidean and extended Euclidean algorithms (revised): These algorithms are impor- 
tant for numerous cryptographic functions and algorithms. The material on the 
Euclidean and extended Euclidean algorithms for integers and for polynomials has 
been completely rewritten to provide a clearer and more systematic treatment. 
Advanced Encryption Standard (revised): AES has emerged as the dominant symmetric 
encryption algorithm, used in a wide variety of applications. Accordingly, this edition has 
dramatically expanded the resources for learning about and understanding this impor- 
tant standard. The chapter on AES has been revised and expanded, with additional illus- 
trations and a detailed example, to clarify the presentation. Examples and assignments 
using Sage have been added. And the book now includes an AES cryptography lab, 
which enables the student to gain hands-on experience with AES cipher internals and 
modes of use. The lab makes use of an AES calculator applet, available at this book’s 
Web site, that can encrypt or decrypt test data values using the AES block cipher. 
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Block Cipher Modes of Operation (revised): The material in Chapter 6 on modes of 
operation has been expanded and the illustrations redrawn for greater clarity. 
Pseudorandom number generation and pseudorandom functions (revised): The treat- 
ment of this important topic has been expanded, with the addition of new material on 
the use of symmetric encryption algorithms and cryptographic hash functions to con- 
struct pseudorandom functions. 

ElGamal encryption and digital signature (new): New sections have been added on 
this popular public-key algorithm. 

Cryptographic hash functions and message authentication codes (revised): The mater- 
ial on hash functions and MAC has been revised and reorganized to provide a clearer 
and more systematic treatment. 

SHA-3 (new): Although the SHA-3 algorithm has yet to be selected, it is important 
for the student to have a grasp of the design criteria for this forthcoming cryptograph- 
ic hash standard. 

Authenticated encryption (new): The book covers the important new algorithms, 
CCM and GCM, which simultaneously provide confidentiality and data integrity. 

Key management and distribution (revised): In the fourth edition, these topics were 
scattered across three chapters. In the fifth edition, the material is revised and consoli- 
dated into a single chapter to provide a unified, systematic treatment. 

Remote user authentication (revised): In the fourth edition, this topic was covered in 
parts of two chapters. In the fifth edition the material is revised and consolidated into 
a single chapter to provide a unified, systematic treatment. 

Federated identity (new): A new section covers this common identity management 
scheme across multiple enterprises and numerous applications and supporting many 
thousands, even millions, of users. 

HTTPS (new): A new section covers this protocol for providing secure communica- 
tion between Web browser and Web server. 

Secure shell (new): SSH, one of the most pervasive applications of encryption tech- 
nology, is covered in a new section. 

DomainKeys Identified Mail (new): A new section covers DKIM, which has become 
the standard means of authenticating e-mail to counter spam. 

Wireless network security (new): A new chapter covers this important area of net- 
work security. The chapter deals with the IEEE 802.11 (WiFi) security standard for 
wireless local area networks; and the Wireless Application Protocol (WAP) security 
standard for communication between a mobile Web browser and a Web server. 

IPsec (revised): The chapter on IPsec has been almost completely rewritten. It now 
covers IPsecv3 and IKEv2. In addition, the presentation has been revised to improve 
clarity and breadth. 

Legal and ethical issues (new): A new online chapter covers these important 
topics. 

Online appendices (new): Fifteen online appendices provide additional breadth and 
depth for the interested student on a variety of topics. 

Sage examples and problems (new): As mentioned, this new edition makes use of the 
open-source, freeware Sage computer algebra application to enable students to have 
hands-on experience with a variety of cryptographic algorithms. 
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With each new edition it is a struggle to maintain a reasonable page count while adding 
new material. In part, this objective is realized by eliminating obsolete material and tighten- 
ing the narrative. For this edition, chapters and appendices that are of less general interest 
have been moved online as individual PDF files. This has allowed an expansion of material 
without the corresponding increase in size and price. 
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The art of war teaches us to rely not on the likelihood of the enemy’s not coming, but 
on our own readiness to receive him; not on the chance of his not attacking, but rather 
on the fact that we have made our position unassailable. 


—The Art of War, Sun Tzu 


This book, with its accompanying Web site, covers a lot of material. Here we give the 
reader an overview. 


0.1 OUTLINE OF THIS BOOK 


Following an introductory chapter, Chapter 1, the book is organized into seven parts: 


Part One: 


Part Two: 


Part Three: 


Part Four: 


Part Five: 


Part Six: 


Part Seven: 


Symmetric Ciphers: Provides a survey of symmetric encryption, including clas- 
sical and modern algorithms. The emphasis is on the two most important algo- 
rithms, the Data Encryption Standard (DES) and the Advanced Encryption 
Standard (AES). This part also covers the most important stream encryption 
algorithm, RC4, and the important topic of pseudorandom number generation. 


Asymmetric Ciphers: Provides a survey of public-key algorithms, 
including RSA (Rivest-Shamir-Adelman) and elliptic curve. 


Cryptographic Data Integrity Algorithms: Begins with a survey of crypto- 
graphic hash functions. This part then covers two approaches to data 
integrity that rely on cryptographic hash functions: message authentica- 
tion codes and digital signatures. 


Mutual Trust: Covers key management and key distribution topics and 
then covers user authentication techniques. 


Network Security and Internet Security: Examines the use of cryptographic 
algorithms and security protocols to provide security over networks and the 
Internet. Topics covered include transport-level security, wireless network 
security, e-mail security, and IP security. 


System Security: Deals with security facilities designed to protect a 
computer system from security threats, including intruders, viruses, and 
worms. This part also looks at firewall technology. 


Legal and Ethical Issues: Deals with the legal and ethical issues related 
to computer and network security. 


A number of online appendices at this book’s Web site cover additional topics 
relevant to the book. 


0.2 A ROADMAP FOR READERS AND INSTRUCTORS 


Subject Matter 


The material in this book is organized into four broad categories: 


e Cryptographic algorithms: This is the study of techniques for ensuring the 
secrecy and/or authenticity of information. The three main areas of study in 
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this category are: (1) symmetric encryption, (2) asymmetric encryption, and 
(3) cryptographic hash functions, with the related topics of message authenti- 
cation codes and digital signatures. 


e Mutual trust: This is the study of techniques and algorithms for providing 
mutual trust in two main areas. First, key management and distribution deals 
with establishing trust in the encryption keys used between two communicating 
entities. Second, user authentication deals with establishing trust in the identity 
of a communicating partner. 


e Network security: This area covers the use of cryptographic algorithms in 
network protocols and network applications. 


e Computer security: In this book, we use this term to refer to the security of 
computers against intruders (e.g., hackers) and malicious software (e.g., 
viruses). Typically, the computer to be secured is attached to a network, and 
the bulk of the threats arise from the network. 


The first two parts of the book deal with two distinct cryptographic approaches: 
symmetric cryptographic algorithms and public-key, or asymmetric, cryptographic 
algorithms. Symmetric algorithms make use of a single key shared by two parties. 
Public-key algorithms make use of two keys: a private key known only to one party 
and a public key available to other parties. 


Topic Ordering 


This book covers a lot of material. For the instructor or reader who wishes a shorter 
treatment, there are a number of opportunities. 

To thoroughly cover the material in the first three parts, the chapters should be 
read in sequence. With the exception of the Advanced Encryption Standard (AES), 
none of the material in Part One requires any special mathematical background. To 
understand AES, it is necessary to have some understanding of finite fields. In turn, 
an understanding of finite fields requires a basic background in prime numbers and 
modular arithmetic. Accordingly, Chapter 4 covers all of these mathematical prelim- 
inaries just prior to their use in Chapter 5 on AES. Thus, if Chapter 5 is skipped, it is 
safe to skip Chapter 4 as well. 

Chapter 2 introduces some concepts that are useful in later chapters of Part 
One. However, for the reader whose sole interest is contemporary cryptography, 
this chapter can be quickly skimmed. The two most important symmetric crypto- 
graphic algorithms are DES and AES, which are covered in Chapters 3 and 5, 
respectively. 

Chapter 6 covers specific techniques for using what are known as block sym- 
metric ciphers. Chapter 7 covers stream ciphers and random number generation. 
These two chapters may be skipped on an initial reading, but this material is refer- 
enced in later parts of the book. 

For Part Two, the only additional mathematical background that is needed is in 
the area of number theory, which is covered in Chapter 8. The reader who has skipped 
Chapters 4 and 5 should first review the material on Sections 4.1 through 4.3. 

The two most widely used general-purpose public-key algorithms are RSA 
and elliptic curve, with RSA enjoying wider acceptance. The reader may wish to skip 
the material on elliptic curve cryptography in Chapter 10, at least on a first reading. 
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In Part Three, the topics in Sections 12.6 and 12.7 are of lesser importance. 
Parts Four, Five, and Six are relatively independent of each other and can be 


read in any order. These three parts assume a basic understanding of the material in 
Parts One, Two, and Three. The four chapters of Part Five, on network and Internet 
security, are relatively independent of one another and can be read in any order. 


0.3 INTERNET AND WEB RESOURCES 


There are a number of resources available on the Internet and the Web to support 
this book and to help readers keep up with developments in this field. 


Web Sites for This Book 


There is a Web page for this book at WilliamStallings.com/Crypto/CryptoSe.html. 
The site includes the following: 


e 


e 


Useful Web sites: There are links to other relevant Web sites, organized by 
chapter, including the sites listed throughout this book. 


Errata sheet: An errata list for this book will be maintained and updated as 
needed. Please e-mail any errors that you spot to me. Errata sheets for my 
other books are at WilliamStallings.com. 


Figures: All of the figures in this book are provided in PDF (Adobe Acrobat) 
format. 


Tables: All of the tables in this book are provided in PDF format. 
Slides: A set of PowerPoint slides are provided, organized by chapter. 


Cryptography and network security courses: There are links to home pages for 
courses based on this book; these pages may be useful to other instructors in 
providing ideas about how to structure their course. 


I also maintain the Computer Science Student Resource Site, at William 


Stallings.com/StudentSupport.html. The purpose of this site is to provide docu- 
ments, information, and links for computer science students and professionals. Links 
and documents are organized into six categories: 


Math: Includes a basic math refresher, a queuing analysis primer, a number 
system primer, and links to numerous math sites 


How-to: Advice and guidance for solving homework problems, writing techni- 
cal reports, and preparing technical presentations 


Research resources: Links to important collections of papers, technical 
reports, and bibliographies 


Miscellaneous: A variety of other useful documents and links. 


Computer science careers: Useful links and documents for those considering a 
career in computer science. 

Humor and other diversions: You have to take your mind off your work once 
in a while. 
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Other Web Sites 


There are numerous Web sites that provide information related to the topics of this 
book. In subsequent chapters, pointers to specific Web sites can be found in the 
Recommended Reading and Web Sites section. Because the addresses for Web sites 
tend to change frequently, the book does not provide URLs. For all of the Web sites 
listed in the book, the appropriate link can be found at this book’s Web site. Other 
links not mentioned in this book will be added to the Web site over time. 


Newsgroups and Forums 


A number of USENET newsgroups are devoted to some aspect of cryptography or 
network security. As with virtually all USENET groups, there is a high noise-to-signal 
ratio, but it is worth experimenting to see if any meet your needs. The most relevant 
are as follows: 


© sci.crypt.research: The best group to follow. This is a moderated newsgroup 
that deals with research topics; postings must have some relationship to the 
technical aspects of cryptology. 


sci.crypt: A general discussion of cryptology and related topics. 


© sci.crypt.random-numbers: A discussion of cryptographic-strength random 
number generators. 


alt.security: A general discussion of security topics. 

© comp.security.misc: A general discussion of computer security topics. 

© comp.security.firewalls: A discussion of firewall products and technology. 
© comp.security.announce: News and announcements from CERT. 

° comp.risks: A discussion of risks to the public from computers and users. 
© comp.virus: A moderated discussion of computer viruses. 


In addition, there are a number of forums dealing with cryptography available 
on the Internet. Among the most worthwhile are 


e Security and Cryptography forum: Sponsored by DevShed. Discusses issues 
related to coding, server applications, network protection, data protection, 
firewalls, ciphers, and the like. 


e Cryptography forum: On Topix. Fairly good focus on technical issues. 
e Security forums: On WindowsSecurity.com. Broad range of forums, including 
cryptographic theory, cryptographic software, firewalls, and malware. 


Links to these forums are provided at this book’s Web site. 


0.4 STANDARDS 


Many of the security techniques and applications described in this book have 
been specified as standards. Additionally, standards have been developed to 
cover management practices and the overall architecture of security mechanisms 
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and services. Throughout this book, we describe the most important standards in 
use or being developed for various aspects of cryptography and network security. 
Various organizations have been involved in the development or promotion of 
these standards. The most important (in the current context) of these organiza- 
tions are as follows: 


National Institute of Standards and Technology: NIST is a U.S. federal agency 
that deals with measurement science, standards, and technology related to US. 
government use and to the promotion of U.S. private-sector innovation. 
Despite its national scope, NIST Federal Information Processing Standards 
(FIPS) and Special Publications (SP) have a worldwide impact. 


Internet Society: ISOC is a professional membership society with worldwide 
organizational and individual membership. It provides leadership in address- 
ing issues that confront the future of the Internet and is the organization 
home for the groups responsible for Internet infrastructure standards, 
including the Internet Engineering Task Force (IETF) and the Internet 
Architecture Board (IAB). These organizations develop Internet standards 
and related specifications, all of which are published as Requests for 
Comments (RFCs). 


ITU-T: The International Telecommunication Union (ITU) is an international 
organization within the United Nations System in which governments and the 
private sector coordinate global telecom networks and services The ITU 
Telecommunication Standardization Sector (ITU-T) is one of the three sectors 
of the ITU. ITU-T’s mission is the production of standards covering all fields of 
telecommunications. ITU-T standards are referred to as Recommendations. 


ISO: The International Organization for Standardization (ISO)! is a world- 
wide federation of national standards bodies from more than 140 countries, 
one from each country. ISO is a nongovernmental organization that pro- 
motes the development of standardization and related activities with a view 
to facilitating the international exchange of goods and services and to devel- 
oping cooperation in the spheres of intellectual, scientific, technological, and 
economic activity. ISO’s work results in international agreements that are 
published as International Standards. 


A more detailed discussion of these organizations is contained in Appendix D. 


'TSO is not an acronym (in which case it would be IOS), but it is a word derived from the Greek, meaning 


equal. 
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CHAPTER 1 / OVERVIEW 


The combination of space, time, and strength that must be considered as the 
basic elements of this theory of defense makes this a fairly complicated matter. 
Consequently, it is not easy to find a fixed point of departure. 


—On War, Carl Von Clausewitz 


KEY POINTS 


© The Open Systems Interconnection (OSI) security architecture provides 
a systematic framework for defining security attacks, mechanisms, and 
services. 


© Security attacks are classified as either passive attacks, which include 
unauthorized reading of a message of file and traffic analysis or active 
attacks, such as modification of messages or files, and denial of service. 


© A security mechanism is any process (or a device incorporating such a 
process) that is designed to detect, prevent, or recover from a security attack. 
Examples of mechanisms are encryption algorithms, digital signatures, and 
authentication protocols. 


® Security services include authentication, access control, data confidentiality, 
data integrity, nonrepudiation, and availability. 


This book focuses on two broad areas: cryptographic algorithms and protocols, which 
have a broad range of applications; and network and Internet security, which rely 
heavily on cryptographic techniques. 

Cryptographic algorithms and protocols can be grouped into four main areas: 


e Symmetric encryption: Used to conceal the contents of blocks or streams of 
data of any size, including messages, files, encryption keys, and passwords. 


e Asymmetric encryption: Used to conceal small blocks of data, such as encryption 
keys and hash function values, which are used in digital signatures. 


e Data integrity algorithms: Used to protect blocks of data, such as messages, 
from alteration. 


e Authentication protocols: These are schemes based on the use of cryptographic 
algorithms designed to authenticate the identity of entities. 


The field of network and Internet security consists of measures to deter, prevent, 
detect, and correct security violations that involve the transmission of informa- 
tion. That is a broad statement that covers a host of possibilities. To give you a 
feel for the areas covered in this book, consider the following examples of 
security violations: 


1. User A transmits a file to user B. The file contains sensitive information 
(e.g., payroll records) that is to be protected from disclosure. User C, who is 
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not authorized to read the file, is able to monitor the transmission and capture 
a copy of the file during its transmission. 


nN 


A network manager, D, transmits a message to a computer, E, under its man- 
agement. The message instructs computer E to update an authorization file to 
include the identities of a number of new users who are to be given access to 
that computer. User F intercepts the message, alters its contents to add or 
delete entries, and then forwards the message to computer E, which accepts 
the message as coming from manager D and updates its authorization file 
accordingly. 


3. Rather than intercept a message, user F constructs its own message with the 
desired entries and transmits that message to computer E as if it had come 
from manager D. Computer E accepts the message as coming from manager D 
and updates its authorization file accordingly. 


4. An employee is fired without warning. The personnel manager sends a 
message to a server system to invalidate the employee’s account. When the 
invalidation is accomplished, the server is to post a notice to the employee’s 
file as confirmation of the action. The employee is able to intercept the 
message and delay it long enough to make a final access to the server to 
retrieve sensitive information. The message is then forwarded, the action 
taken, and the confirmation posted. The employee’s action may go 
unnoticed for some considerable time. 


5. A message is sent from a customer to a stockbroker with instructions for 
various transactions. Subsequently, the investments lose value and the 
customer denies sending the message. 


Although this list by no means exhausts the possible types of network security 
violations, it illustrates the range of concerns of network security. 


1.1 COMPUTER SECURITY CONCEPTS 


A Definition of Computer Security 


The NIST Computer Security Handbook [NIST95] defines the term computer security 
as follows: 


COMPUTER SECURITY 


The protection afforded to an automated information system in order to attain the 


applicable objectives of preserving the integrity, availability, and confidentiality of 
information system resources (includes hardware, software, firmware, information/ 
data, and telecommunications). 
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This definition introduces three key objectives that are at the heart of 
computer security: 


e Confidentiality: This term covers two related concepts: 


Data! confidentiality: Assures that private or confidential information is 
not made available or disclosed to unauthorized individuals. 


Privacy: Assures that individuals control or influence what information 
related to them may be collected and stored and by whom and to whom 
that information may be disclosed. 


e Integrity: This term covers two related concepts: 


Data integrity: Assures that information and programs are changed only in 
a specified and authorized manner. 


System integrity: Assures that a system performs its intended function in an 
unimpaired manner, free from deliberate or inadvertent unauthorized 
manipulation of the system. 


e Availability: Assures that systems work promptly and service is not denied to 
authorized users. 


These three concepts form what is often referred to as the CIA triad 
(Figure 1.1). The three concepts embody the fundamental security objectives for 
both data and for information and computing services. For example, the NIST 
standard FIPS 199 (Standards for Security Categorization of Federal Information 


services 


Figure 1.1 The Security Requirements 
Triad 


'RFC 2828 defines information as “facts and ideas, which can be represented (encoded) as various 
forms of data,” and data as “information in a specific physical representation, usually a sequence 
of symbols that have meaning; especially a representation of information that can be processed or 
produced by a computer.” Security literature typically does not make much of a distinction, nor does 
this book. 
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and Information Systems) lists confidentiality, integrity, and availability as the three 
security objectives for information and for information systems. FIPS 199 provides a 
useful characterization of these three objectives in terms of requirements and the 
definition of a loss of security in each category: 


e Confidentiality: Preserving authorized restrictions on information access 
and disclosure, including means for protecting personal privacy and propri- 
etary information. A loss of confidentiality is the unauthorized disclosure of 
information. 


e Integrity: Guarding against improper information modification or destruc- 
tion, including ensuring information nonrepudiation and authenticity. 
A loss of integrity is the unauthorized modification or destruction of 
information. 


e Availability: Ensuring timely and reliable access to and use of information. 
A loss of availability is the disruption of access to or use of information or an 
information system. 


Although the use of the CIA triad to define security objectives is well established, 
some in the security field feel that additional concepts are needed to present a complete 
picture. Two of the most commonly mentioned are as follows: 


e Authenticity: The property of being genuine and being able to be verified and 
trusted; confidence in the validity of a transmission, a message, or message 
originator. This means verifying that users are who they say they are and that 
each input arriving at the system came from a trusted source. 


e Accountability: The security goal that generates the requirement for actions 
of an entity to be traced uniquely to that entity. This supports nonrepudia- 
tion, deterrence, fault isolation, intrusion detection and prevention, and 
after-action recovery and legal action. Because truly secure systems are not 
yet an achievable goal, we must be able to trace a security breach to 
a responsible party. Systems must keep records of their activities to permit 
later forensic analysis to trace security breaches or to aid in transaction 
disputes. 


Examples 


We now provide some examples of applications that illustrate the requirements just 
enumerated.” For these examples, we use three levels of impact on organizations or 
individuals should there be a breach of security (i.e., a loss of confidentiality, 
integrity, or availability). These levels are defined in FIPS PUB 199: 


e Low: The loss could be expected to have a limited adverse effect on organiza- 
tional operations, organizational assets, or individuals. A limited adverse effect 
means that, for example, the loss of confidentiality, integrity, or availability 


These examples are taken from a security policy document published by the Information Technology 
Security and Privacy Office at Purdue University. 
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might (i) cause a degradation in mission capability to an extent and duration 
that the organization is able to perform its primary functions, but the effec- 
tiveness of the functions is noticeably reduced; (ii) result in minor damage to 
organizational assets; (iii) result in minor financial loss; or (iv) result in minor 
harm to individuals. 


e Moderate: The loss could be expected to have a serious adverse effect on 
organizational operations, organizational assets, or individuals. A serious 
adverse effect means that, for example, the loss might (i) cause a significant 
degradation in mission capability to an extent and duration that the organi- 
zation is able to perform its primary functions, but the effectiveness of 
the functions is significantly reduced; (ii) result in significant damage to 
organizational assets; (iii) result in significant financial loss; or (iv) result in 
significant harm to individuals that does not involve loss of life or serious, 
life-threatening injuries. 

e High: The loss could be expected to have a severe or catastrophic adverse 
effect on organizational operations, organizational assets, or individuals. 
A severe or catastrophic adverse effect means that, for example, the loss 
might (i) cause a severe degradation in or loss of mission capability to an 
extent and duration that the organization is not able to perform one or 
more of its primary functions; (ii) result in major damage to organizational 
assets; (iii) result in major financial loss; or (iv) result in severe or cata- 
strophic harm to individuals involving loss of life or serious, life-threatening 
injuries. 


CONFIDENTIALITY Student grade information is an asset whose confidentiality 
is considered to be highly important by students. In the United States, the release 
of such information is regulated by the Family Educational Rights and Privacy 
Act (FERPA). Grade information should only be available to students, their 
parents, and employees that require the information to do their job. Student 
enrollment information may have a moderate confidentiality rating. While still 
covered by FERPA, this information is seen by more people on a daily basis, is 
less likely to be targeted than grade information, and results in less damage if 
disclosed. Directory information, such as lists of students or faculty or 
departmental lists, may be assigned a low confidentiality rating or indeed no 
rating. This information is typically freely available to the public and published 
on a school’s Web site. 


InTEGRITY Several aspects of integrity are illustrated by the example of a hospital 
patient’s allergy information stored in a database. The doctor should be able to trust 
that the information is correct and current. Now suppose that an employee (e.g., a 
nurse) who is authorized to view and update this information deliberately falsifies 
the data to cause harm to the hospital. The database needs to be restored to a 
trusted basis quickly, and it should be possible to trace the error back to the person 
responsible. Patient allergy information is an example of an asset with a high 
requirement for integrity. Inaccurate information could result in serious harm or 
death to a patient and expose the hospital to massive liability. 
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An example of an asset that may be assigned a moderate level of integrity 
requirement is a Web site that offers a forum to registered users to discuss some 
specific topic. Either a registered user or a hacker could falsify some entries or 
deface the Web site. If the forum exists only for the enjoyment of the users, brings in 
little or no advertising revenue, and is not used for something important such as 
research, then potential damage is not severe. The Web master may experience 
some data, financial, and time loss. 

An example of a low integrity requirement is an anonymous online poll. Many 
Web sites, such as news organizations, offer these polls to their users with very few 
safeguards. However, the inaccuracy and unscientific nature of such polls is well 
understood. 


AVAILABILITY The more critical a component or service, the higher is the level of 
availability required. Consider a system that provides authentication services for 
critical systems, applications, and devices. An interruption of service results in the 
inability for customers to access computing resources and staff to access 
the resources they need to perform critical tasks. The loss of the service 
translates into a large financial loss in lost employee productivity and potential 
customer loss. 

An example of an asset that would typically be rated as having a moderate 
availability requirement is a public Web site for a university; the Web site provides 
information for current and prospective students and donors. Such a site is not a 
critical component of the university’s information system, but its unavailability will 
cause some embarrassment. 

An online telephone directory lookup application would be classified as a 
low availability requirement. Although the temporary loss of the application may be 
an annoyance, there are other ways to access the information, such as a hardcopy 
directory or the operator. 


The Challenges of Computer Security 


Computer and network security is both fascinating and complex. Some of the reasons 
follow: 


1. Security is not as simple as it might first appear to the novice. The require- 
ments seem to be straightforward; indeed, most of the major requirements 
for security services can be given self-explanatory, one-word labels: confi- 
dentiality, authentication, nonrepudiation, or integrity. But the mechanisms 
used to meet those requirements can be quite complex, and understanding 
them may involve rather subtle reasoning. 


nN 


. In developing a particular security mechanism or algorithm, one must always 
consider potential attacks on those security features. In many cases, successful 
attacks are designed by looking at the problem in a completely different way, 
therefore exploiting an unexpected weakness in the mechanism. 


3. Because of point 2, the procedures used to provide particular services are often 
counterintuitive. Typically, a security mechanism is complex, and it is not obvious 
from the statement of a particular requirement that such elaborate measures are 
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needed. It is only when the various aspects of the threat are considered that 
elaborate security mechanisms make sense. 


4. Having designed various security mechanisms, it is necessary to decide where 
to use them. This is true both in terms of physical placement (e.g., at what 
points in a network are certain security mechanisms needed) and in a logical 
sense [e.g., at what layer or layers of an architecture such as TCP/IP 
(Transmission Control Protocol/Internet Protocol) should mechanisms be 
placed]. 


5. Security mechanisms typically involve more than a particular algorithm or 
protocol. They also require that participants be in possession of some secret 
information (e.g., an encryption key), which raises questions about the 
creation, distribution, and protection of that secret information. There also 
may be a reliance on communications protocols whose behavior may compli- 
cate the task of developing the security mechanism. For example, if the proper 
functioning of the security mechanism requires setting time limits on the 
transit time of a message from sender to receiver, then any protocol or 
network that introduces variable, unpredictable delays may render such time 
limits meaningless. 


6. Computer and network security is essentially a battle of wits between a perpetrator 
who tries to find holes and the designer or administrator who tries to close them. 
The great advantage that the attacker has is that he or she need only find a single 
weakness, while the designer must find and eliminate all weaknesses to achieve 
perfect security. 


7. There is a natural tendency on the part of users and system managers to perceive 
little benefit from security investment until a security failure occurs. 


8. Security requires regular, even constant, monitoring, and this is difficult in today’s 
short-term, overloaded environment. 


9. Security is still too often an afterthought to be incorporated into a system after 
the design is complete rather than being an integral part of the design process. 


10. Many users and even security administrators view strong security as an imped- 
iment to efficient and user-friendly operation of an information system or use 
of information. 


The difficulties just enumerated will be encountered in numerous ways as we 
examine the various security threats and mechanisms throughout this book. 


1.2. THE OSI SECURITY ARCHITECTURE 


To assess effectively the security needs of an organization and to evaluate and choose 
various security products and policies, the manager responsible for security needs 
some systematic way of defining the requirements for security and characterizing the 
approaches to satisfying those requirements. This is difficult enough in a centralized 
data processing environment; with the use of local and wide area networks, the 
problems are compounded. 
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Table 1.1 Threats and Attacks (RFC 2828) 


Threat 

A potential for violation of security, which exists when there is a circumstance, capability, action, 
or event that could breach security and cause harm. That is, a threat is a possible danger that 
might exploit a vulnerability. 


Attack 

An assault on system security that derives from an intelligent threat; that is, an intelligent act that is a 
deliberate attempt (especially in the sense of a method or technique) to evade security services and 
violate the security policy of a system. 


ITU-T? Recommendation X.800, Security Architecture for OSI, defines such a 
systematic approach.’ The OSI security architecture is useful to managers as a way 
of organizing the task of providing security. Furthermore, because this architecture 
was developed as an international standard, computer and communications vendors 
have developed security features for their products and services that relate to this 
structured definition of services and mechanisms. 

For our purposes, the OSI security architecture provides a useful, if abstract, 
overview of many of the concepts that this book deals with. The OSI security archi- 
tecture focuses on security attacks, mechanisms, and services. These can be defined 
briefly as 


e Security attack: Any action that compromises the security of information 
owned by an organization. 


e Security mechanism: A process (or a device incorporating such a process) that 
is designed to detect, prevent, or recover from a security attack. 


e Security service: A processing or communication service that enhances the 
security of the data processing systems and the information transfers of an 
organization. The services are intended to counter security attacks, and they 
make use of one or more security mechanisms to provide the service. 


In the literature, the terms threat and attack are commonly used to mean more 
or less the same thing. Table 1.1 provides definitions taken from RFC 2828, Internet 
Security Glossary. 


1.3 SECURITY ATTACKS 


A useful means of classifying security attacks, used both in X.800 and RFC 2828, is 
in terms of passive attacks and active attacks. A passive attack attempts to learn or 
make use of information from the system but does not affect system resources. An 
active attack attempts to alter system resources or affect their operation. 


3The International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T) 
is a United Nations-sponsored agency that develops standards, called Recommendations, relating to 
telecommunications and to open systems interconnection (OSI). 

‘The OSI security architecture was developed in the context of the OSI protocol architecture, which is 
described in Appendix L. However, for our purposes in this chapter, an understanding of the OSI protocol 
architecture is not required. 
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Passive Attacks 


Passive attacks are in the nature of eavesdropping on, or monitoring of, transmis- 
sions. The goal of the opponent is to obtain information that is being transmitted. 
Two types of passive attacks are the release of message contents and traffic 
analysis. 

The release of message contents is easily understood (Figure 1.2a). A telephone 
conversation, an electronic mail message, and a transferred file may contain sensitive 
or confidential information. We would like to prevent an opponent from learning the 
contents of these transmissions. 

A second type of passive attack, traffic analysis, is subtler (Figure 1.2b). 
Suppose that we had a way of masking the contents of messages or other 
information traffic so that opponents, even if they captured the message, could 
not extract the information from the message. The common technique for 
masking contents is encryption. If we had encryption protection in place, an 
opponent might still be able to observe the pattern of these messages. The 
opponent could determine the location and identity of communicating hosts and 
could observe the frequency and length of messages being exchanged. This 
information might be useful in guessing the nature of the communication that 
was taking place. 

Passive attacks are very difficult to detect, because they do not involve any 
alteration of the data. Typically, the message traffic is sent and received in an appar- 
ently normal fashion, and neither the sender nor receiver is aware that a third party 
has read the messages or observed the traffic pattern. However, it is feasible to pre- 
vent the success of these attacks, usually by means of encryption. Thus, the empha- 
sis in dealing with passive attacks is on prevention rather than detection. 


Active Attacks 


Active attacks involve some modification of the data stream or the creation of a false 
stream and can be subdivided into four categories: masquerade, replay, modification 
of messages, and denial of service. 

A masquerade takes place when one entity pretends to be a different entity 
(Figure 1.3a). A masquerade attack usually includes one of the other forms of active 
attack. For example, authentication sequences can be captured and replayed after a 
valid authentication sequence has taken place, thus enabling an authorized entity 
with few privileges to obtain extra privileges by impersonating an entity that has 
those privileges. 

Replay involves the passive capture of a data unit and its subsequent retrans- 
mission to produce an unauthorized effect (Figure 1.3b). 

Modification of messages simply means that some portion of a legitimate 
message is altered, or that messages are delayed or reordered, to produce an unau- 
thorized effect (Figure 1.3c). For example, a message meaning “Allow John Smith 
to read confidential file accounts” is modified to mean “Allow Fred Brown to read 
confidential file accounts.” 

The denial of service prevents or inhibits the normal use or management of 
communications facilities (Figure 1.3d). This attack may have a specific target; for 
example, an entity may suppress all messages directed to a particular destination 
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(a) Release of message contents 
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(b) Traffic analysis 


Figure 1.2 Passive Attacks 


(e.g., the security audit service). Another form of service denial is the disruption of an 
entire network, either by disabling the network or by overloading it with messages so 
as to degrade performance. 

Active attacks present the opposite characteristics of passive attacks. Whereas 
passive attacks are difficult to detect, measures are available to prevent their success. 
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Figure 1.3 Active attacks (Continued) 


On the other hand, it is quite difficult to prevent active attacks absolutely because of 
the wide variety of potential physical, software, and network vulnerabilities. Instead, 
the goal is to detect active attacks and to recover from any disruption or 
delays caused by them. If the detection has a deterrent effect, it may also contribute 
to prevention. 
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Figure 1.3 Active attacks 


1.4 SECURITY SERVICES 


X.800 defines a security service as a service that is provided by a protocol layer of 
communicating open systems and that ensures adequate security of the systems or 
of data transfers. Perhaps a clearer definition is found in RFC 2828, which provides 
the following definition: a processing or communication service that is provided by 
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a system to give a specific kind of protection to system resources; security services 
implement security policies and are implemented by security mechanisms. 

X.800 divides these services into five categories and fourteen specific services 
(Table 1.2). We look at each category in turn.> 


Table 1.2 


Security Services (X.800) 


AUTHENTICATION 


The assurance that the communicating entity is the 
one that it claims to be. 


Peer Entity Authentication 

Used in association with a logical connection to 
provide confidence in the identity of the entities 
connected. 


Data-Origin Authentication 


In a connectionless transfer, provides assurance that 
the source of received data is as claimed. 


ACCESS CONTROL 


The prevention of unauthorized use of a resource 

(i.e., this service controls who can have access to a 
resource, under what conditions access can occur, 

and what those accessing the resource are allowed 
to do). 


DATA CONFIDENTIALITY 


The protection of data from unauthorized 
disclosure. 


Connection Confidentiality 
The protection of all user data on a connection. 


Connectionless Confidentiality 
The protection of all user data in a single data block 


Selective-Field Confidentiality 
The confidentiality of selected fields within the user 
data on a connection or in a single data block. 


Traffic-Flow Confidentiality 
The protection of the information that might be 
derived from observation of traffic flows. 


DATA INTEGRITY 


The assurance that data received are exactly as 
sent by an authorized entity (i.e., contain no 
modification, insertion, deletion, or replay). 


Connection Integrity with Recovery 

Provides for the integrity of all user data on a 
connection and detects any modification, insertion, 
deletion, or replay of any data within an entire data 
sequence, with recovery attempted. 


Connection Integrity without Recovery 
As above, but provides only detection without recovery. 


Selective-Field Connection Integrity 

Provides for the integrity of selected fields within the 
user data of a data block transferred over a connec- 
tion and takes the form of determination of whether 
the selected fields have been modified, inserted, 
deleted, or replayed. 


Connectionless Integrity 

Provides for the integrity of a single connectionless 
data block and may take the form of detection of 
data modification. Additionally, a limited form of 
replay detection may be provided. 


Selective-Field Connectionless Integrity 

Provides for the integrity of selected fields within a single 
connectionless data block; takes the form of determina- 
tion of whether the selected fields have been modified. 


NONREPUDIATION 


Provides protection against denial by one of the 
entities involved in a communication of having 
participated in all or part of the communication. 


Nonrepudiation, Origin 
Proof that the message was sent by the specified party. 


Nonrepudiation, Destination 
Proof that the message was received by the specified 
party. 


>There is no universal agreement about many of the terms used in the security literature. For example, 
the term integrity is sometimes used to refer to all aspects of information security. The term authentication 
is sometimes used to refer both to verification of identity and to the various functions listed under 
integrity in this chapter. Our usage here agrees with both X.800 and RFC 2828. 
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Authentication 


The authentication service is concerned with assuring that a communication is 
authentic. In the case of a single message, such as a warning or alarm signal, the 
function of the authentication service is to assure the recipient that the message is 
from the source that it claims to be from. In the case of an ongoing interaction, such 
as the connection of a terminal to a host, two aspects are involved. First, at the time 
of connection initiation, the service assures that the two entities are authentic, that 
is, that each is the entity that it claims to be. Second, the service must assure that the 
connection is not interfered with in such a way that a third party can masquerade as 
one of the two legitimate parties for the purposes of unauthorized transmission or 
reception. 
Two specific authentication services are defined in X.800: 


e Peer entity authentication: Provides for the corroboration of the identity 
of a peer entity in an association. Two entities are considered peers if 
they implement to same protocol in different systems; e.g., two TCP mod- 
ules in two communicating systems. Peer entity authentication is provided 
for use at the establishment of, or at times during the data transfer phase 
of, a connection. It attempts to provide confidence that an entity is not 
performing either a masquerade or an unauthorized replay of a previous 
connection. 


e Data origin authentication: Provides for the corroboration of the source 
of a data unit. It does not provide protection against the duplication or 
modification of data units. This type of service supports applications like 
electronic mail, where there are no prior interactions between the commu- 
nicating entities. 


Access Control 


In the context of network security, access control is the ability to limit and control 
the access to host systems and applications via communications links. To achieve 
this, each entity trying to gain access must first be identified, or authenticated, so 
that access rights can be tailored to the individual. 


Data Confidentiality 


Confidentiality is the protection of transmitted data from passive attacks. With 
respect to the content of a data transmission, several levels of protection can be 
identified. The broadest service protects all user data transmitted between two users 
over a period of time. For example, when a TCP connection is set up between two 
systems, this broad protection prevents the release of any user data transmitted over 
the TCP connection. Narrower forms of this service can also be defined, including 
the protection of a single message or even specific fields within a message. These 
refinements are less useful than the broad approach and may even be more complex 
and expensive to implement. 

The other aspect of confidentiality is the protection of traffic flow from analysis. 
This requires that an attacker not be able to observe the source and destination, 
frequency, length, or other characteristics of the traffic on a communications facility. 
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Data Integrity 


As with confidentiality, integrity can apply to a stream of messages, a single message, 
or selected fields within a message. Again, the most useful and straightforward 
approach is total stream protection. 

A connection-oriented integrity service, one that deals with a stream of 
messages, assures that messages are received as sent with no duplication, inser- 
tion, modification, reordering, or replays. The destruction of data is also covered 
under this service. Thus, the connection-oriented integrity service addresses both 
message stream modification and denial of service. On the other hand, a connec- 
tionless integrity service, one that deals with individual messages without regard 
to any larger context, generally provides protection against message modification 
only. 

We can make a distinction between service with and without recovery. Because 
the integrity service relates to active attacks, we are concerned with detection rather 
than prevention. If a violation of integrity is detected, then the service may simply 
report this violation, and some other portion of software or human intervention is 
required to recover from the violation. Alternatively, there are mechanisms available 
to recover from the loss of integrity of data, as we will review subsequently. 
The incorporation of automated recovery mechanisms is, in general, the more 
attractive alternative. 


Nonrepudiation 


Nonrepudiation prevents either sender or receiver from denying a transmitted 
message. Thus, when a message is sent, the receiver can prove that the alleged 
sender in fact sent the message. Similarly, when a message is received, the sender can 
prove that the alleged receiver in fact received the message. 


Availability Service 


Both X.800 and RFC 2828 define availability to be the property of a system or a 
system resource being accessible and usable upon demand by an authorized 
system entity, according to performance specifications for the system (i.e., a 
system is available if it provides services according to the system design whenever 
users request them). A variety of attacks can result in the loss of or reduction in 
availability. Some of these attacks are amenable to automated countermeasures, 
such as authentication and encryption, whereas others require some sort of 
physical action to prevent or recover from loss of availability of elements of a 
distributed system. 

X.800 treats availability as a property to be associated with various security 
services. However, it makes sense to call out specifically an availability service. An 
availability service is one that protects a system to ensure its availability. This service 
addresses the security concerns raised by denial-of-service attacks. It depends on 
proper management and control of system resources and thus depends on access 
control service and other security services. 
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1.5 SECURITY MECHANISMS 


Table 1.3 lists the security mechanisms defined in X.800. The mechanisms are 
divided into those that are implemented in a specific protocol layer, such as TCP or 
an application-layer protocol, and those that are not specific to any particular 
protocol layer or security service. These mechanisms will be covered in the appro- 
priate places in the book. So we do not elaborate now, except to comment on the 


Table 1.3 Security Mechanisms (X.800) 


SPECIFIC SECURITY MECHANISMS 


May be incorporated into the appropriate protocol 
layer in order to provide some of the OSI security 
services. 


Encipherment 

The use of mathematical algorithms to transform 
data into a form that is not readily intelligible. The 
transformation and subsequent recovery of the 
data depend on an algorithm and zero or more 
encryption keys. 


Digital Signature 

Data appended to, or a cryptographic transformation 
of, a data unit that allows a recipient of the data unit 
to prove the source and integrity of the data unit and 
protect against forgery (e.g., by the recipient). 


Access Control 
A variety of mechanisms that enforce access rights to 
resources. 


Data Integrity 
A variety of mechanisms used to assure the integrity 
of a data unit or stream of data units. 


Authentication Exchange 
A mechanism intended to ensure the identity of an 
entity by means of information exchange. 


Traffic Padding 
The insertion of bits into gaps in a data stream to 
frustrate traffic analysis attempts. 


Routing Control 

Enables selection of particular physically secure 
routes for certain data and allows routing changes, 
especially when a breach of security is suspected. 


Notarization 
The use of a trusted third party to assure certain 
properties of a data exchange. 


PERVASIVE SECURITY MECHANISMS 


Mechanisms that are not specific to any particular 
OSI security service or protocol layer. 


Trusted Functionality 
That which is perceived to be correct with respect to 
some criteria (e.g., as established by a security policy). 


Security Label 

The marking bound to a resource (which may be a 
data unit) that names or designates the security 
attributes of that resource. 


Event Detection 
Detection of security-relevant events. 


Security Audit Trail 

Data collected and potentially used to facilitate a 
security audit, which is an independent review and 
examination of system records and activities. 


Security Recovery 

Deals with requests from mechanisms, such as event 
handling and management functions, and takes 
recovery actions. 


ve 


fable 1.4 Relationship Between Security Services and Mechanisms 


Mechanism 

Digital Access Data Authentication Traffic Routing 
Service Encipherment | Signature | Control | Integrity Exchange Padding | Control | Notarization 
Peer Entity Authentication Me xi AE 
Data Origin Authentication Ye iG 
Access Control Ye 
Confidentiality Ve Ye 
Traffic Flow Confidentiality YW ve Ye 
Data Integrity ay Ye ny 
Nonrepudiation ve Ye ¥ 
Availability we ne 
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definition of encipherment. X.800 distinguishes between reversible encipherment 
mechanisms and irreversible encipherment mechanisms. A reversible encipherment 
mechanism is simply an encryption algorithm that allows data to be encrypted and 
subsequently decrypted. Irreversible encipherment mechanisms include hash algo- 
rithms and message authentication codes, which are used in digital signature and 
message authentication applications. 

Table 1.4, based on one in X.800, indicates the relationship between security 
services and security mechanisms. 


1.6 A MODEL FOR NETWORK SECURITY 


A model for much of what we will be discussing is captured, in very general terms, in 
Figure 1.4. A message is to be transferred from one party to another across some sort 
of Internet service. The two parties, who are the principals in this transaction, must 
cooperate for the exchange to take place. A logical information channel is estab- 
lished by defining a route through the Internet from source to destination and by the 
cooperative use of communication protocols (e.g., TCP/IP) by the two principals. 

Security aspects come into play when it is necessary or desirable to protect 
the information transmission from an opponent who may present a threat to confi- 
dentiality, authenticity, and so on. All the techniques for providing security have 
two components: 


e A security-related transformation on the information to be sent. Examples 
include the encryption of the message, which scrambles the message so that it is 
unreadable by the opponent, and the addition of a code based on the contents 
of the message, which can be used to verify the identity of the sender. 
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Figure 1.4 Model for Network Security 
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e Some secret information shared by the two principals and, it is hoped, 
unknown to the opponent. An example is an encryption key used in conjunc- 
tion with the transformation to scramble the message before transmission and 
unscramble it on reception.° 


A trusted third party may be needed to achieve secure transmission. For 
example, a third party may be responsible for distributing the secret information to 
the two principals while keeping it from any opponent. Or a third party may be 
needed to arbitrate disputes between the two principals concerning the authenticity 
of a message transmission. 

This general model shows that there are four basic tasks in designing a particular 
security service: 


1. Design an algorithm for performing the security-related transformation. 
The algorithm should be such that an opponent cannot defeat its purpose. 


2. Generate the secret information to be used with the algorithm. 


Ge 
. 


Develop methods for the distribution and sharing of the secret information. 


> 


Specify a protocol to be used by the two principals that makes use of the security 
algorithm and the secret information to achieve a particular security service. 


Parts One through Five of this book concentrate on the types of security mecha- 
nisms and services that fit into the model shown in Figure 1.4. However, there are other 
security-related situations of interest that do not neatly fit this model but are consid- 
ered in this book. A general model of these other situations is illustrated by Figure 1.5, 
which reflects a concern for protecting an information system from unwanted access. 
Most readers are familiar with the concerns caused by the existence of hackers, who 
attempt to penetrate systems that can be accessed over a network. The hacker can 
be someone who, with no malign intent, simply gets satisfaction from breaking and 
entering a computer system. The intruder can be a disgruntled employee who wishes 
to do damage or a criminal who seeks to exploit computer assets for financial gain 
(e.g., obtaining credit card numbers or performing illegal money transfers). 


Information system 


Computing resources 
Opponent (processor, memory, I/O) 


—human (e.g., hacker) Data 
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function 3 
Internal security controls 


Figure 1.5 Network Access Security Model 


Part Two discusses a form of encryption, known as a symmetric encryption, in which only one of the two 
principals needs to have the secret information. 
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Another type of unwanted access is the placement in a computer system of 
logic that exploits vulnerabilities in the system and that can affect application pro- 
grams as well as utility programs, such as editors and compilers. Programs can pre- 
sent two kinds of threats: 


e Information access threats: Intercept or modify data on behalf of users who 
should not have access to that data. 


e Service threats: Exploit service flaws in computers to inhibit use by legitimate 
users. 


Viruses and worms are two examples of software attacks. Such attacks can be 
introduced into a system by means of a disk that contains the unwanted logic con- 
cealed in otherwise useful software. They can also be inserted into a system across a 
network; this latter mechanism is of more concern in network security. 

The security mechanisms needed to cope with unwanted access fall into two 
broad categories (see Figure 1.5). The first category might be termed a gatekeeper 
function. It includes password-based login procedures that are designed to deny 
access to all but authorized users and screening logic that is designed to detect and 
reject worms, viruses, and other similar attacks. Once either an unwanted user or 
unwanted software gains access, the second line of defense consists of a variety of 
internal controls that monitor activity and analyze stored information in an 
attempt to detect the presence of unwanted intruders. These issues are explored in 
Part Six. 


1.7 RECOMMENDED READING AND WEB SITES 


[STALO02] provides a broad introduction to both computer and network security. [SCHNO0] 
is valuable reading for any practitioner in the field of computer or network security: It 
discusses the limitations of technology, and cryptography in particular, in providing security 
and the need to consider the hardware, the software implementation, the networks, and the 
people involved in providing and attacking security. 

It is useful to read some of the classic tutorial papers on computer security; these 
provide a historical perspective from which to appreciate current work and thinking. The 
papers to read are [WARE79], [BROW72], [SALT75], [SHAN77], and [SUMM84]. Two 
more recent, short treatments of computer security are [ANDR0O4] and [LAMP04]. 
[NIST95] is an exhaustive (290 pages) treatment of the subject. Another good treatment is 
[NRC91]. Also useful is [FRAS97]. 
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NIST95 National Institute of Standards and Technology. An Introduction to Computer 
Security: The NIST Handbook. Special Publication 800-12, October 1995. 
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Recommended Web Sites: 


The following Web sites’ are of general interest related to cryptography and network security: 


e 


IETF Security Area: Material related to Internet security standardization efforts. 

The Cryptography FAQ: Lengthy and worthwhile FAQ covering all aspects of cryptog- 
raphy. 

Tom Dunigan’s Security page: An excellent list of pointers to cryptography and net- 
work security Web sites. 

Peter Gutmann’s home page: Good collection of cryptography material. 

Helgar Lipma’s Cryptology Pointers: Another excellent list of pointers to cryptography 
and network security Web sites. 

Cryptology ePrint archive: Provides rapid access to recent research in cryptology; con- 
sists of a collection of unrefereed papers. 

IEEE Technical Committee on Security and Privacy: Copies of their newsletter and 
information on IEEE-related activities. 

Computer Security Resource Center: Maintained by the National Institute of 
Standards and Technology (NIST); contains a broad range of information on security 
threats, technology, and standards. 

Computer and Network Security Reference Index: A good index to vendor and commer- 
cial products, FAQs, newsgroup archives, papers, and other Web sites. 

Security Focus: A wide variety of security information, with an emphasis on vendor 
products and end-user concerns. 


SANS Institute: Similar to Security Focus. Extensive collection of white papers. 


7Because URLs sometimes change, they are not included. For all of the Web sites listed in this and 
subsequent chapters, the appropriate link is at this book’s Web site at williamstallings.com/Crypto/ 
CryptoSe.html. 
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Risks Digest: Forum on risks to the public in computers and related systems. 


Institute for Security and Open Methodologies: An open, collaborative security 
research community. Lots of interesting information. 


Center for Internet Security: Provides freeware benchmark and scoring tools for eval- 
uating security of operating systems, network devices, and applications. Includes case 
studies and technical papers. 


Key Terms 


access control 


active threat 


authentication 


authenticity 
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denial of service 
encryption 
integrity 
intruder 


passive threat 
replay 

security attacks 
security mechanisms 


availability 
data confidentiality 
data integrity 


masquerade 
nonrepudiation 
OSI security architecture 


security services 
traffic analysis 


Review Questions 


1.1 What is the OSI security architecture? 

1.2 What is the difference between passive and active security threats? 

1.3 List and briefly define categories of passive and active security attacks. 

1.4 List and briefly define categories of security services. 

1.5 List and briefly define categories of security mechanisms. 

Problems 

1.1 Consider an automated teller machine (ATM) in which users provide a personal 
identification number (PIN) and a card for account access. Give examples of confi- 
dentiality, integrity, and availability requirements associated with the system and, in 
each case, indicate the degree of importance of the requirement. 

1.2 Repeat Problem 1.1 for a telephone switching system that routes calls through a 
switching network based on the telephone number requested by the caller. 

1.3. Consider a desktop publishing system used to produce documents for various 
organizations. 
a. Give an example of a type of publication for which confidentiality of the stored 

data is the most important requirement. 
b. Give an example of a type of publication in which data integrity is the most 
important requirement. 

c. Give an example in which system availability is the most important requirement. 

1.4 For each of the following assets, assign a low, moderate, or high impact level for the 


loss of confidentiality, availability, and integrity, respectively. Justify your answers. 

a. An organization managing public information on its Web server. 

b. A law enforcement organization managing extremely sensitive investigative 
information. 
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d. 


e 


A financial organization managing routine administrative information (not privacy- 
related information). 

An information system used for large acquisitions in a contracting organization 
contains both sensitive, pre-solicitation phase contract information and routine 
administrative information. Assess the impact for the two data sets separately and 
the information system as a whole. 

A power plant contains a SCADA (supervisory control and data acquisition) system 
controlling the distribution of electric power for a large military installation. The 
SCADA system contains both real-time sensor data and routine administrative 
information. Assess the impact for the two data sets separately and the information 
system as a whole. 


Draw a matrix similar to Table 1.4 that shows the relationship between security services 
and attacks. 


Draw a matrix similar to Table 1.4 that shows the relationship between security 
mechanisms and attacks. 
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“T am fairly familiar with all the forms of secret writings, and am myself the 
author of a trifling monograph upon the subject, in which I analyze one hundred 
and sixty separate ciphers,” said Holmes. 


—The Adventure of the Dancing Men, Sir Arthur Conan Doyle 


KEY POINTS 


® Symmetric encryption is a form of cryptosystem in which encryption and 
decryption are performed using the same key. It is also known as conven- 
tional encryption. 


® Symmetric encryption transforms plaintext into ciphertext using a secret 
key and an encryption algorithm. Using the same key and a decryption 
algorithm, the plaintext is recovered from the ciphertext. 


® The two types of attack on an encryption algorithm are cryptanalysis, 
based on properties of the encryption algorithm, and brute-force, which 
involves trying all possible keys. 


® Traditional (precomputer) symmetric ciphers use substitution and/or 
transposition techniques. Substitution techniques map plaintext elements 
(characters, bits) into ciphertext elements. Transposition techniques sys- 
tematically transpose the positions of plaintext elements. 

® Rotor machines are sophisticated precomputer hardware devices that use 
substitution techniques. 

® Steganography is a technique for hiding a secret message within a larger 
one in such a way that others cannot discern the presence or contents of the 
hidden message. 


Symmetric encryption, also referred to as conventional encryption or single-key 
encryption, was the only type of encryption in use prior to the development of public- 
key encryption in the 1970s. It remains by far the most widely used of the two types of 
encryption. Part One examines a number of symmetric ciphers. In this chapter, we 
begin with a look at a general model for the symmetric encryption process; this will 
enable us to understand the context within which the algorithms are used. Next, we 
examine a variety of algorithms in use before the computer era. Finally, we look briefly 
at a different approach known as steganography. Chapters 3 and 5 examine the two 
most widely used symmetric cipher: DES and AES. 

Before beginning, we define some terms. An original message is known as the 
plaintext, while the coded message is called the ciphertext. The process of converting 
from plaintext to ciphertext is known as enciphering or encryption; restoring the plain- 
text from the ciphertext is deciphering or decryption. The many schemes used for 
encryption constitute the area of study known as cryptography. Such a scheme is 
known as a cryptographic system or a cipher. Techniques used for deciphering a 
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message without any knowledge of the enciphering details fall into the area of 
cryptanalysis. Cryptanalysis is what the layperson calls “breaking the code.” The areas 
of cryptography and cryptanalysis together are called cryptology. 


2.1 SYMMETRIC CIPHER MODEL 


A symmetric encryption scheme has five ingredients (Figure 2.1): 


Plaintext: This is the original intelligible message or data that is fed into the 
algorithm as input. 


Encryption algorithm: The encryption algorithm performs various substitu- 
tions and transformations on the plaintext. 


Secret key: The secret key is also input to the encryption algorithm. The key is 
a value independent of the plaintext and of the algorithm. The algorithm will 
produce a different output depending on the specific key being used at the 
time. The exact substitutions and transformations performed by the algorithm 
depend on the key. 


Ciphertext: This is the scrambled message produced as output. It depends on 
the plaintext and the secret key. For a given message, two different keys will 
produce two different ciphertexts. The ciphertext is an apparently random 
stream of data and, as it stands, is unintelligible. 


Decryption algorithm: This is essentially the encryption algorithm run in 
reverse. It takes the ciphertext and the secret key and produces the original 
plaintext. 


There are two requirements for secure use of conventional encryption: 


We need a strong encryption algorithm. At a minimum, we would like the 
algorithm to be such that an opponent who knows the algorithm and has 
access to one or more ciphertexts would be unable to decipher the ciphertext 
or figure out the key. This requirement is usually stated in a stronger form: The 
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Figure 2.1 Simplified Model of Symmetric Encryption 
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opponent should be unable to decrypt ciphertext or discover the key even if he 
or she is in possession of a number of ciphertexts together with the plaintext 
that produced each ciphertext. 


N 


. Sender and receiver must have obtained copies of the secret key in a secure 
fashion and must keep the key secure. If someone can discover the key and 
knows the algorithm, all communication using this key is readable. 


We assume that it is impractical to decrypt a message on the basis of the 
ciphertext plus knowledge of the encryption/decryption algorithm. In other words, 
we do not need to keep the algorithm secret; we need to keep only the key secret. 
This feature of symmetric encryption is what makes it feasible for widespread use. 
The fact that the algorithm need not be kept secret means that manufacturers can 
and have developed low-cost chip implementations of data encryption algorithms. 
These chips are widely available and incorporated into a number of products. With 
the use of symmetric encryption, the principal security problem is maintaining the 
secrecy of the key. 

Let us take a closer look at the essential elements of a symmetric encryp- 
tion scheme, using Figure 2.2. A source produces a message in plaintext, 
X = [X,, Xo, ..., Xy]. The M elements of X are letters in some finite alphabet. 
Traditionally, the alphabet usually consisted of the 26 capital letters. Nowadays, 
the binary alphabet {0, 1} is typically used. For encryption, a key of the form 
K = [K, Ko, ..., Kj] is generated. If the key is generated at the message source, 
then it must also be provided to the destination by means of some secure chan- 
nel. Alternatively, a third party could generate the key and securely deliver it to 
both source and destination. 


Cryptanalyst 


Message ee eon Decryper Destination 
source algorithm algorithm 


Secure channel 


Key 
source 


Figure 2.2. Model of Symmetric Cryptosystem 
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With the message X and the encryption key K as input, the encryption algo- 
rithm forms the ciphertext Y = [Y1, Yo, ..., Yy]. We can write this as 


Y = E(K, X) 


This notation indicates that Y is produced by using encryption algorithm E as a 
function of the plaintext X, with the specific function determined by the value of 
the key K. 

The intended receiver, in possession of the key, is able to invert the 
transformation: 


X = D(K, Y) 


An opponent, observing Y but not having access to K or X, may attempt to 
recover X or K or both X and K. It is assumed that the opponent knows the encryption 
(E) and decryption (D) algorithms. If the opponent is interested in only this particular 
message, then the focus of the effort is to recover X by generating a plaintext estimate 
X. Often, however, the opponent is interested in being able to read future messages as 
well, in which case an attempt is made to recover K by generating an estimate K. 


Cryptography 
Cryptographic systems are characterized along three independent dimensions: 


1. The type of operations used for transforming plaintext to ciphertext. All 
encryption algorithms are based on two general principles: substitution, in 
which each element in the plaintext (bit, letter, group of bits or letters) is 
mapped into another element, and transposition, in which elements in the 
plaintext are rearranged. The fundamental requirement is that no informa- 
tion be lost (that is, that all operations are reversible). Most systems, 
referred to as product systems, involve multiple stages of substitutions and 
transpositions. 


N 


. The number of keys used. If both sender and receiver use the same key, the 
system is referred to as symmetric, single-key, secret-key, or conventional encryp- 
tion. If the sender and receiver use different keys, the system is referred to as 
asymmetric, two-key, or public-key encryption. 

3. The way in which the plaintext is processed. A block cipher processes the 

input one block of elements at a time, producing an output block for each 

input block. A stream cipher processes the input elements continuously, 
producing output one element at a time, as it goes along. 


Cryptanalysis and Brute-Force Attack 


Typically, the objective of attacking an encryption system is to recover the key in use 
rather than simply to recover the plaintext of a single ciphertext. There are two gen- 
eral approaches to attacking a conventional encryption scheme: 


e Cryptanalysis: Cryptanalytic attacks rely on the nature of the algorithm plus 
perhaps some knowledge of the general characteristics of the plaintext or 
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even some sample plaintext—ciphertext pairs. This type of attack exploits the 
characteristics of the algorithm to attempt to deduce a specific plaintext or to 
deduce the key being used. 


e Brute-force attack: The attacker tries every possible key on a piece of cipher- 
text until an intelligible translation into plaintext is obtained. On average, half 
of all possible keys must be tried to achieve success. 


If either type of attack succeeds in deducing the key, the effect is catastrophic: 
All future and past messages encrypted with that key are compromised. 

We first consider cryptanalysis and then discuss brute-force attacks. 

Table 2.1 summarizes the various types of cryptanalytic attacks based on the 
amount of information known to the cryptanalyst. The most difficult problem is pre- 
sented when all that is available is the ciphertext only. In some cases, not even the 
encryption algorithm is known, but in general, we can assume that the opponent 
does know the algorithm used for encryption. One possible attack under these cir- 
cumstances is the brute-force approach of trying all possible keys. If the key space is 
very large, this becomes impractical. Thus, the opponent must rely on an analysis of 
the ciphertext itself, generally applying various statistical tests to it. To use this 
approach, the opponent must have some general idea of the type of plaintext that is 
concealed, such as English or French text, an EXE file, a Java source listing, an 
accounting file, and so on. 


Table 2.1 Types of Attacks on Encrypted Messages 


Type of Attack Known to Cryptanalyst 


Ciphertext Only e Encryption algorithm 
¢ Ciphertext 


Known Plaintext e Encryption algorithm 
¢ Ciphertext 


¢ One or more plaintext-ciphertext pairs formed with the secret key 


Chosen Plaintext e Encryption algorithm 
¢ Ciphertext 


e Plaintext message chosen by cryptanalyst, together with its corresponding ciphertext 
generated with the secret key 


Chosen Ciphertext e Encryption algorithm 
¢ Ciphertext 


¢ Ciphertext chosen by cryptanalyst, together with its corresponding decrypted 
plaintext generated with the secret key 


Chosen Text e Encryption algorithm 
¢ Ciphertext 


e Plaintext message chosen by cryptanalyst, together with its corresponding 
ciphertext generated with the secret key 


¢ Ciphertext chosen by cryptanalyst, together with its corresponding decrypted 
plaintext generated with the secret key 
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The ciphertext-only attack is the easiest to defend against because the oppo- 
nent has the least amount of information to work with. In many cases, however, the 
analyst has more information. The analyst may be able to capture one or more 
plaintext messages as well as their encryptions. Or the analyst may know that cer- 
tain plaintext patterns will appear in a message. For example, a file that is encoded 
in the Postscript format always begins with the same pattern, or there may be a 
standardized header or banner to an electronic funds transfer message, and so on. 
All these are examples of known plaintext. With this knowledge, the analyst may be 
able to deduce the key on the basis of the way in which the known plaintext is 
transformed. 

Closely related to the known-plaintext attack is what might be referred to as a 
probable-word attack. If the opponent is working with the encryption of some gen- 
eral prose message, he or she may have little knowledge of what is in the message. 
However, if the opponent is after some very specific information, then parts of the 
message may be known. For example, if an entire accounting file is being transmitted, 
the opponent may know the placement of certain key words in the header of the file. 
As another example, the source code for a program developed by Corporation X 
might include a copyright statement in some standardized position. 

If the analyst is able somehow to get the source system to insert into the 
system a message chosen by the analyst, then a chosen-plaintext attack is possible. 
An example of this strategy is differential cryptanalysis, explored in Chapter 3. In 
general, if the analyst is able to choose the messages to encrypt, the analyst may 
deliberately pick patterns that can be expected to reveal the structure of the key. 

Table 2.1 lists two other types of attack: chosen ciphertext and chosen text. 
These are less commonly employed as cryptanalytic techniques but are nevertheless 
possible avenues of attack. 

Only relatively weak algorithms fail to withstand a ciphertext-only attack. 
Generally, an encryption algorithm is designed to withstand a known-plaintext 
attack. 

Two more definitions are worthy of note. An encryption scheme is 
unconditionally secure if the ciphertext generated by the scheme does not con- 
tain enough information to determine uniquely the corresponding plaintext, no 
matter how much ciphertext is available. That is, no matter how much time an 
opponent has, it is impossible for him or her to decrypt the ciphertext simply 
because the required information is not there. With the exception of a scheme 
known as the one-time pad (described later in this chapter), there is no encryp- 
tion algorithm that is unconditionally secure. Therefore, all that the users of an 
encryption algorithm can strive for is an algorithm that meets one or both of the 
following criteria: 


e The cost of breaking the cipher exceeds the value of the encrypted information. 


e The time required to break the cipher exceeds the useful lifetime of the 
information. 


An encryption scheme is said to be computationally secure if either of the 
foregoing two criteria are met. Unfortunately, it is very difficult to estimate the 
amount of effort required to cryptanalyze ciphertext successfully. 
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Table 2.2 Average Time Required for Exhaustive Key Search 


Number of Time Required at 1 Time Required at 
Key Size (bits) Alternative Keys Decryption/ps 10° Decryptions/ys 


32) OE = AB SO? 214s = 35.8 minutes 2.15 milliseconds 


56 PPD = 7/2) SS 0 2°us = 1142 years 10.01 hours 


128 QOe = Bal se i108 2'27us = 5.4 X 10% years 5.4 x 10!8 years 


168 DES B77 Se HO 267s = 5.9 x 10° years 5.9 X 10° years 


26 characters 


he 26 6 12 6 
(permutation) 26! = 4 x 10 2 X 10°°us = 6.4 X 10% years 6.4 x 10° years 


All forms of cryptanalysis for symmetric encryption schemes are designed to 
exploit the fact that traces of structure or pattern in the plaintext may survive 
encryption and be discernible in the ciphertext. This will become clear as we exam- 
ine various symmetric encryption schemes in this chapter. We will see in Part Two 
that cryptanalysis for public-key schemes proceeds from a fundamentally different 
premise, namely, that the mathematical properties of the pair of keys may make it 
possible for one of the two keys to be deduced from the other. 

A brute-force attack involves trying every possible key until an intelligible 
translation of the ciphertext into plaintext is obtained. On average, half of all possi- 
ble keys must be tried to achieve success. Table 2.2 shows how much time is involved 
for various key spaces. Results are shown for four binary key sizes. The 56-bit key 
size is used with the Data Encryption Standard (DES) algorithm, and the 168-bit 
key size is used for triple DES. The minimum key size specified for Advanced 
Encryption Standard (AES) is 128 bits. Results are also shown for what are called 
substitution codes that use a 26-character key (discussed later), in which all possible 
permutations of the 26 characters serve as keys. For each key size, the results are 
shown assuming that it takes 1 ys to perform a single decryption, which is a reason- 
able order of magnitude for today’s machines. With the use of massively parallel 
organizations of microprocessors, it may be possible to achieve processing rates 
many orders of magnitude greater. The final column of Table 2.2 considers the 
results for a system that can process 1 million keys per microsecond. As you can see, 
at this performance level, DES can no longer be considered computationally secure. 


2.2 SUBSTITUTION TECHNIQUES 


In this section and the next, we examine a sampling of what might be called classical 
encryption techniques. A study of these techniques enables us to illustrate the basic 
approaches to symmetric encryption used today and the types of cryptanalytic 
attacks that must be anticipated. 

The two basic building blocks of all encryption techniques are substitution and 
transposition. We examine these in the next two sections. Finally, we discuss a system 
that combines both substitution and transposition. 
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A substitution technique is one in which the letters of plaintext are replaced 
by other letters or by numbers or symbols.! If the plaintext is viewed as a sequence 
of bits, then substitution involves replacing plaintext bit patterns with ciphertext bit 
patterns. 


Caesar Cipher 


The earliest known, and the simplest, use of a substitution cipher was by Julius 
Caesar. The Caesar cipher involves replacing each letter of the alphabet with the let- 
ter standing three places further down the alphabet. For example, 


plain: meet me after the toga party 
cipher: PHHW PH DIWHU WKH WRJD SDUWB 


Note that the alphabet is wrapped around, so that the letter following Z is A. 
We can define the transformation by listing all possibilities, as follows: 


plain: abcdefghijklmnopgqrstuvwxyaz 
cipher: DEFGHIJKLMNOPQRSTUVWXYZABC 


Let us assign a numerical equivalent to each letter: 


a c d e f g h i j k l m 
0 1 2 3 4 5 6 7 8 9 10 11 12 
n fe) p q C s t u Vv w x y Z 


13 14 15 | 16 17 | 18 | 19 | 20 | 21 | 22 23 24 25 


Then the algorithm can be expressed as follows. For each plaintext letter p, substi- 
tute the ciphertext letter C:? 


C = E@, p) = (p + 3) mod 26 
A shift may be of any amount, so that the general Caesar algorithm is 
C = E(k, p) = (p + k) mod 26 (2.1) 
where k takes on a value in the range 1 to 25. The decryption algorithm is simply 


p = D(k, C) = (C — k) mod 26 (2.2) 


‘When letters are involved, the following conventions are used in this book. Plaintext is always in lowercase; 
ciphertext is in uppercase; key values are in italicized lowercase. 

We define a mod n to be the remainder when a is divided by n. For example, 11 mod 7 = 4. See Chapter 4 
for a further discussion of modular arithmetic. 
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If it is known that a given ciphertext is a Caesar cipher, then a brute-force 
cryptanalysis is easily performed: simply try all the 25 possible keys. Figure 2.3 
shows the results of applying this strategy to the example ciphertext. In this case, the 


plaintext leaps out as occupying the third line. 


Three important characteristics of this problem enabled us to use a brute- 


force cryptanalysis: 


1. The encryption and decryption algorithms are known. 


2. There are only 25 keys to try. 


3. The language of the plaintext is known and easily recognizable. 


In most networking situations, we can assume that the algorithms are known. 
What generally makes brute-force cryptanalysis impractical is the use of an algo- 
rithm that employs a large number of keys. For example, the triple DES algorithm, 
examined in Chapter 6, makes use of a 168-bit key, giving a key space of 


greater than 3.7 X 10° possible keys. 
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toga 
eniz 
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ozqsx 
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epgin 
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whyaf 
vgxze 
ufwyd 
tevxc 


Figure 2. 


3 Brute-Force Cryptanalysis of Caesar 


Cipher 
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Figure 2.4 Sample of Compressed Text 


The third characteristic is also significant. If the language of the plaintext is 
unknown, then plaintext output may not be recognizable. Furthermore, the 
input may be abbreviated or compressed in some fashion, again making recogni- 
tion difficult. For example, Figure 2.4 shows a portion of a text file compressed 
using an algorithm called ZIP. If this file is then encrypted with a simple substi- 
tution cipher (expanded to include more than just 26 alphabetic characters), 
then the plaintext may not be recognized when it is uncovered in the brute-force 
cryptanalysis. 


Monoalphabetic Ciphers 


With only 25 possible keys, the Caesar cipher is far from secure. A dramatic increase 
in the key space can be achieved by allowing an arbitrary substitution. Before pro- 
ceeding, we define the term permutation. A permutation of a finite set of elements S 
is an ordered sequence of all the elements of S, with each element appearing exactly 
once. For example, if S = {a, b, c}, there are six permutations of S: 


abc, acb, bac, bea, cab, cba 


In general, there are n! permutations of a set of n elements, because the first 
element can be chosen in one of 1 ways, the second in n — 1 ways, the third inn — 2 
ways, and so on. 

Recall the assignment for the Caesar cipher: 


plain: abcdefghigjkimnopgqrstuvwxyaz 
cipher: DE FGHIJKLMNOPQRSTUVWXYZABC 


If, instead, the “cipher” line can be any permutation of the 26 alphabetic characters, 
then there are 26! or greater than 4 x 107° possible keys. This is 10 orders of magni- 
tude greater than the key space for DES and would seem to eliminate brute-force 
techniques for cryptanalysis. Such an approach is referred to as a monoalphabetic 
substitution cipher, because a single cipher alphabet (mapping from plain alphabet 
to cipher alphabet) is used per message. 

There is, however, another line of attack. If the cryptanalyst knows the 
nature of the plaintext (e.g., noncompressed English text), then the analyst can 
exploit the regularities of the language. To see how such a cryptanalysis might 
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proceed, we give a partial example here that is adapted from one in [SINK66]. 
The ciphertext to be solved is 


UZQSOVUOHXMOPVGPOZPEVSGZWSZOPFP 
VUEPHZHMDZSHZOWSF PAPPI 
EPYEPOPDZSZUF POM! 


BZWPFUPZHMI 


ESXUD 


BM 


ETSXA 


DT SV PQUZWYMXUZU 


DJUDTMOHMQO 


HSX 


As a first step, the relative frequency of the letters can be determined and 
compared to a standard frequency distribution for English, such as is shown in 
Figure 2.5 (based on [LEWA00]). If the message were long enough, this technique 
alone might be sufficient, but because this is a relatively short message, we cannot 
expect an exact match. In any case, the relative frequencies of the letters in the 
ciphertext (in percentages) are as follows: 


P 13.33 H 5.83 F 3.33 B 1.67 C 0.00 
Z 11.67 D 5.00 W 3.33 i 167 K 0.00 
S 8.33 E 5.00 Q 2.50 Y 167 L 0.00 
U_ 8.33 V 417 T 2.50 I 0.83 N 0.00 
O 7.50 X 417 A 167 J 0.83 R 0.00 
M 6.67 
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Comparing this breakdown with Figure 2.5, it seems likely that cipher letters 
P and Z are the equivalents of plain letters e and t, but it is not certain which is 
which. The letters S, U,O,M, and H are all of relatively high frequency and probably 
correspond to plain letters from the set {a, h, i, n, 0, r, s}. The letters with the lowest 
frequencies (namely, A, B, G, Y, I, J) are likely included in the set {b, j,k, q, v, x, z}. 

There are a number of ways to proceed at this point. We could make some 
tentative assignments and start to fill in the plaintext to see if it looks like a reasonable 
“skeleton” of a message. A more systematic approach is to look for other regularities. 
For example, certain words may be known to be in the text. Or we could look for 
repeating sequences of cipher letters and try to deduce their plaintext equivalents. 

A powerful tool is to look at the frequency of two-letter combinations, known 
as digrams. A table similar to Figure 2.5 could be drawn up showing the relative fre- 
quency of digrams. The most common such digram is th. In our ciphertext, the most 
common digram is ZW, which appears three times. So we make the correspondence 
of Z with t and W with h. Then, by our earlier hypothesis, we can equate P with e. 
Now notice that the sequence ZWP appears in the ciphertext, and we can translate 
that sequence as “the.” This is the most frequent trigram (three-letter combination) 
in English, which seems to indicate that we are on the right track. 

Next, notice the sequence ZWSZ in the first line. We do not know that these 
four letters form a complete word, but if they do, it is of the form th_t. If so, S 
equates with a. 

So far, then, we have 


UZQSOVUOHXMOPVGPOZPEVSGZWSZOPFPESXUDBMETSXAIZ 
ta e ete athateea a 
VUEPHZHMDZSHZOWSF PAPPDTSVPQUZWYMXUZUHSX 
et ta t hae ee ae th toa 
EPYEPOPDZSZUF POMBZWPFUPZHMDJUDTMOHMQO 
e eetat e the ie 


Only four letters have been identified, but already we have quite a bit of the 
message. Continued analysis of frequencies plus trial and error should easily yield a 
solution from this point. The complete plaintext, with spaces added between words, 
follows: 


it was disclosed yesterday that several informal but 


direct contacts have been made with political 
representatives of the viet cong in moscow 


Monoalphabetic ciphers are easy to break because they reflect the frequency 
data of the original alphabet. A countermeasure is to provide multiple substitutes, 
known as homophones, for a single letter. For example, the letter e could be assigned 
a number of different cipher symbols, such as 16, 74, 35, and 21, with each homo- 
phone assigned to a letter in rotation or randomly. If the number of symbols assigned 
to each letter is proportional to the relative frequency of that letter, then single-letter 
frequency information is completely obliterated. The great mathematician Carl 


44 CHAPTER 2 / CLASSICAL ENCRYPTION TECHNIQUES 


Friedrich Gauss believed that he had devised an unbreakable cipher using homo- 
phones. However, even with homophones, each element of plaintext affects only one 
element of ciphertext, and multiple-letter patterns (e.g., digram frequencies) still 
survive in the ciphertext, making cryptanalysis relatively straightforward. 

Two principal methods are used in substitution ciphers to lessen the extent to 
which the structure of the plaintext survives in the ciphertext: One approach is to 
encrypt multiple letters of plaintext, and the other is to use multiple cipher alphabets. 
We briefly examine each. 


Playfair Cipher 


The best-known multiple-letter encryption cipher is the Playfair, which treats digrams 
in the plaintext as single units and translates these units into ciphertext digrams.° 

The Playfair algorithm is based on the use of a 5 x 5 matrix of letters con- 
structed using a keyword. Here is an example, solved by Lord Peter Wimsey in 
Dorothy Sayers’s Have His Carcase:* 


M/O|N/| AJR 
C | Jet || 32 D 
E|F|G {IW |K 
LiP}|Q{|S{T 
U|Vi|W] xX {|Z 


In this case, the keyword is monarchy. The matrix is constructed by filling in 
the letters of the keyword (minus duplicates) from left to right and from top to bot- 
tom, and then filling in the remainder of the matrix with the remaining letters in 
alphabetic order. The letters I and J count as one letter. Plaintext is encrypted two 
letters at a time, according to the following rules: 


1. Repeating plaintext letters that are in the same pair are separated with a filler 
letter, such as x,so that balloon would be treated as ba 1x lo on. 


2. Two plaintext letters that fall in the same row of the matrix are each replaced by 
the letter to the right, with the first element of the row circularly following the 
last. For example, ar is encrypted as RM. 


3. Two plaintext letters that fall in the same column are each replaced by the letter 
beneath, with the top element of the column circularly following the last. For 
example, mu is encrypted as CM. 


4. Otherwise, each plaintext letter in a pair is replaced by the letter that lies in its 
own row and the column occupied by the other plaintext letter. Thus, hs 
becomes BP and ea becomes IM (or JM, as the encipherer wishes). 


The Playfair cipher is a great advance over simple monoalphabetic ciphers. 
For one thing, whereas there are only 26 letters, there are 26 x 26 = 676 digrams, so 


3This cipher was actually invented by British scientist Sir Charles Wheatstone in 1854, but it bears the name 
of his friend Baron Playfair of St. Andrews, who championed the cipher at the British foreign office. 
4The book provides an absorbing account of a probable-word attack. 
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that identification of individual digrams is more difficult. Furthermore, the relative 
frequencies of individual letters exhibit a much greater range than that of digrams, 
making frequency analysis much more difficult. For these reasons, the Playfair 
cipher was for a long time considered unbreakable. It was used as the standard field 
system by the British Army in World War I and still enjoyed considerable use by the 
U.S. Army and other Allied forces during World War II. 

Despite this level of confidence in its security, the Playfair cipher is relatively 
easy to break, because it still leaves much of the structure of the plaintext language 
intact. A few hundred letters of ciphertext are generally sufficient. 

One way of revealing the effectiveness of the Playfair and other ciphers is shown 
in Figure 2.6, based on [SIMM93]. The line labeled plaintext plots the frequency distri- 
bution of the more than 70,000 alphabetic characters in the Encyclopaedia Britannica 
article on cryptology.° This is also the frequency distribution of any monoalphabetic 
substitution cipher, because the frequency values for individual letters are the same, 
just with different letters substituted for the original letters. The plot was developed in 
the following way: The number of occurrences of each letter in the text was counted 
and divided by the number of occurrences of the letter e (the most frequently used 
letter). As a result, e has a relative frequency of 1, t of about 0.76, and so on. The points 
on the horizontal axis correspond to the letters in order of decreasing frequency. 

Figure 2.6 also shows the frequency distribution that results when the text is 
encrypted using the Playfair cipher. To normalize the plot, the number of occurrences 
of each letter in the ciphertext was again divided by the number of occurrences of e 
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Figure 2.6 Relative Frequency of Occurrence of Letters 


>I am indebted to Gustavus Simmons for providing the plots and explaining their method of construction. 
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in the plaintext. The resulting plot therefore shows the extent to which the frequency 
distribution of letters, which makes it trivial to solve substitution ciphers, is masked 
by encryption. If the frequency distribution information were totally concealed in the 
encryption process, the ciphertext plot of frequencies would be flat, and cryptanalysis 
using ciphertext only would be effectively impossible. As the figure shows, the 
Playfair cipher has a flatter distribution than does plaintext, but nevertheless, it 
reveals plenty of structure for a cryptanalyst to work with. 


Hill Cipher® 


Another interesting multiletter cipher is the Hill cipher, developed by the mathe- 
matician Lester Hill in 1929. 


CONCEPTS FROM LINEAR ALGEBRA Before describing the Hill cipher, let us briefly 
review some terminology from linear algebra. In this discussion, we are concerned 
with matrix arithmetic modulo 26. For the reader who needs a refresher on matrix 
multiplication and inversion, see Appendix E. 

We define the inverse M! of a square matrix M by the equation 
M(M~!) = M"!M = L.where [is the identity matrix. I is a square matrix that is all 
zeros except for ones along the main diagonal from upper left to lower right. The 
inverse of a matrix does not always exist, but when it does, it satisfies the preceding 
equation. For example, 


a-(} > A“! mod 26 = (7 a 
17 3 1 15 


ae ey eee oo 
(47x 9) +(3X 1) (7 X 2) + (3 X 15) 
53. 130 1 0 
7. i 79 ) nee é ) 
To explain how the inverse of a matrix is computed, we begin by with the con- 
cept of determinant. For any square matrix (m x m), the determinant equals the sum 
of all the products that can be formed by taking exactly one element from each row 


and exactly one element from each column, with certain of the product terms pre- 
ceded by a minus sign. For a 2 x 2 matrix, 


& fd 
ky ka 
the determinant is k,,ky. — k,2k>,. For a 3 X 3 matrix, the value of the determi- 


mant is kyyk9k33 + kyyka9ky3 + Ksykyk23 — kaikaaky3 — Kkoikiaks3 — kykspkp3. 
If a square matrix A has a nonzero determinant, then the inverse of the matrix is 


°This cipher is somewhat more difficult to understand than the others in this chapter, but it illustrates an 
important point about cryptanalysis that will be useful later on. This subsection can be skipped on a first 
reading. 
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computed as [A ‘]ii = (det A) '(—1)'"(Dj), where (Dj;) is the subdeterminant 
formed by deleting the jth row and the ith column of A, det(A) is the determinant 
of A, and (det A)! is the multiplicative inverse of (det A) mod 26. 

Continuing our example, 


5 8 
act ( i) = (5 X 3) — (8 X 17) = -121 mod 26 = 9 


We can show that 9-'mod 26 = 3, because 9 X 3 = 27mod 26 = 1 (see 
Chapter 4 or Appendix E). Therefore, we compute the inverse of A as 


5 8 
A= 
@ :) 
3 -8 3 18 9 54 9 2 
A! mod 26 = 3 =3 = = 
_— © :) € 2 c . & 2 
THE Hitt ALGoriTHM This encryption algorithm takes m successive plaintext letters 
and substitutes for them m ciphertext letters. The substitution is determined by m 


linear equations in which each character is assigned a numerical value 
(a = 0,b = 1,...,z = 25). For m = 3, the system can be described as 


Cy = (kypi + ky2p2 + ky3p3)mod 26 
Co = (kypi + kapp2 + ky3p3)mod 26 
C3 = (k31p1 + k32p2 + k33p3) mod 26 


This can be expressed in terms of row vectors and matrices:’ 
ky ky kag 
(C1 C2 €3) = (P Po p3)\ kx kaa kag Jmod 26 
kz, Kap kag 


or 
C = PK mod 26 


where C and P are row vectors of length 3 representing the plaintext and ciphertext, 
and K is a3 X 3 matrix representing the encryption key. Operations are performed 
mod 26. 

For example, consider the plaintext “paymoremoney” and use the encryp- 
tion key 


17 17 ~=5 
K =]21 18 21 
2 2 19 


7Some cryptography books express the plaintext and ciphertext as column vectors, so that the column 
vector is placed after the matrix rather than the row vector placed before the matrix. Sage uses row vectors, 
so we adopt that convention. 
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The first three letters of the plaintext are represented by the vector (15 0 24). Then 
(15 0 24)K = (303 303 531) mod 26 = (171711) = RRL. Continuing in this fash- 
ion, the ciphertext for the entire plaintext is RRLMWBKASPDH. 

Decryption requires using the inverse of the matrix K. We can compute 
det K = 23, and therefore, (det K) 'mod 26 = 17. We can then compute the 
inverse as 


4 9 15 
K!'=/15 17 6 
24 +O 17 
This is demonstrated as 
17 17 = 5 4 9 15 443 442 442 1 0 O 
21 18 21 4/15 17 +6 |=] 858 495 780 Jmod26={]0 1 O 
2 2 19/\24 0 17 494 52 365 0 0 1 


It is easily seen that if the matrix K ! is applied to the ciphertext, then the 
plaintext is recovered. 
In general terms, the Hill system can be expressed as 


C = E(K, P) = PK mod 26 
P = D(K, C) = CK! mod 26 = PKK '=P 


As with Playfair, the strength of the Hill cipher is that it completely hides 
single-letter frequencies. Indeed, with Hill, the use of a larger matrix hides more fre- 
quency information. Thus, a 3 X 3 Hill cipher hides not only single-letter but also 
two-letter frequency information. 

Although the Hill cipher is strong against a ciphertext-only attack, it is 
easily broken with a known plaintext attack. For an m X m Hill cipher, suppose 
we have m plaintext-ciphertext pairs, each of length m. We label the pairs 
P= (PyjPij---Pmj)andC; = (cy; cyj---C,j) such that C; = P,;K for 1 <j =m and 
for some unknown key matrix K. Now define two m X m matrices X = (p,) and 
Y = (c;). Then we can form the matrix equation Y = XK. If X has an inverse, then 
we can determine K = X_'Y. If X is not invertible, then a new version of X can 
be formed with additional plaintext-ciphertext pairs until an invertible X is 
obtained. 

Consider this example. Suppose that the plaintext “hillcipher” is encrypted 
using a2 X 2 Hill cipher to yield the ciphertext HCRZSSXNSP. Thus, we know that 
(78)K mod 26 = (72); (1111)K mod 26 = (17 25); and so on. Using the first two 
plaintext-ciphertext pairs, we have 


7 2 7 8 
(7, a t )Kmod 26 


The inverse of X can be computed: 


& ae: i 
11 11 1 23 
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K- (7 aN eee =) ars -(° ) 
~\4 23/\47 25)  \308 s77f/meeP Ag 5 


This result is verified by testing the remaining plaintext-ciphertext pairs. 


SO 


Polyalphabetic Ciphers 


Another way to improve on the simple monoalphabetic technique is to use different 
monoalphabetic substitutions as one proceeds through the plaintext message. The 
general name for this approach is polyalphabetic substitution cipher. All these tech- 
niques have the following features in common: 


1. A set of related monoalphabetic substitution rules is used. 


2. A key determines which particular rule is chosen for a given transformation. 


VIGENERE CIPHER The best known, and one of the simplest, polyalphabetic ciphers 
is the Vigenére cipher. In this scheme, the set of related monoalphabetic substitution 
rules consists of the 26 Caesar ciphers with shifts of 0 through 25. Each cipher 
is denoted by a key letter, which is the ciphertext letter that substitutes for 
the plaintext letter a. Thus, a Caesar cipher with a shift of 3 is denoted by the key 
value d. 

We can express the Vigenére cipher in the following manner. Assume a 


sequence of plaintext letters P = po, P1, Po, ---; Pn—1 and a key consisting of the 
sequence of letters K = ko, ky, ko, ..., Ky ,—1, where typically m <n.The sequence of 
ciphertext letters C = Co, Cy, Co, ..., C,_1 is calculated as follows: 


C= Co, C1, Co, Se Ch-1 = E(K, #) = E[(Ko, ki, kp, aegis Kiel): (Po, P1, Pr» ae > Pn-1)] 
= (po + ko) mod 26, (p, + k,)mod 26, ..., (Pm—1 + km—-1) mod 26, 
(Pm + ko)mod 26, (py+1 + k,)mod 26, ..., (Pon—1 + kKm—-1)mod 26, ... 


Thus, the first letter of the key is added to the first letter of the plaintext, mod 26, the 
second letters are added, and so on through the first m letters of the plaintext. For 
the next m letters of the plaintext, the key letters are repeated. This process contin- 
ues until all of the plaintext sequence is encrypted. A general equation of the 
encryption process is 


C; = (Dp; + Kimod ind) mod 26 (2.3) 


Compare this with Equation (2.1) for the Caesar cipher. In essence, each 
plaintext character is encrypted with a different Caesar cipher, depending on the 
corresponding key character. Similarly, decryption is a generalization of 
Equation (2.2): 


Pies (CG; _ Rimedims) mod 26 (2.4) 


To encrypt a message, a key is needed that is as long as the message. Usually, 
the key is a repeating keyword. For example, if the keyword is deceptive, the 
message “we are discovered save yourself” is encrypted as 
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key: deceptivedeceptivedeceptive 
plaintext: wearediscoveredsaveyourself 
ciphertext: ZICVIWONGRZGVTIWAVZHCOYGLMGJI 


Expressed numerically, we have the following result. 


key 3} 4]2)/4/15)19}) 8 | 21} 4) 3 ) 4 )2 | 4 | 15 
plaintext 22) 4/0/17) 4/3 | 8 | 18} 2 | 14) 21] 4 | 17) 4 
ciphertext 25 | 8 | 2 | 21 | 19 | 22} 16/13} 6 | 17 | 25 | 6 | 21 | 19 
key 19} 8 | 21} 4}, 3} 4)2 )4 4)15}19} 8 | 21) 4 
plaintext 3/18} O | 21] 4 | 24) 14] 20} 17) 18} 4 | 11 
ciphertext 22} 0} 21)25) 7 | 2 | 16/24} 6 | 11} 12} 6] 9 


The strength of this cipher is that there are multiple ciphertext letters for each 
plaintext letter, one for each unique letter of the keyword. Thus, the letter frequency 
information is obscured. However, not all knowledge of the plaintext structure is 
lost. For example, Figure 2.6 shows the frequency distribution for a Vigenére cipher 
with a keyword of length 9. An improvement is achieved over the Playfair cipher, 
but considerable frequency information remains. 

It is instructive to sketch a method of breaking this cipher, because the method 
reveals some of the mathematical principles that apply in cryptanalysis. 

First, suppose that the opponent believes that the ciphertext was encrypted 
using either monoalphabetic substitution or a Vigenére cipher. A simple test can 
be made to make a determination. If a monoalphabetic substitution is used, then 
the statistical properties of the ciphertext should be the same as that of the 
language of the plaintext. Thus, referring to Figure 2.5, there should be one cipher 
letter with a relative frequency of occurrence of about 12.7%, one with about 
9.06%, and so on. If only a single message is available for analysis, we would not 
expect an exact match of this small sample with the statistical profile of the plain- 
text language. Nevertheless, if the correspondence is close, we can assume a 
monoalphabetic substitution. 

If, on the other hand, a Vigenére cipher is suspected, then progress depends on 
determining the length of the keyword, as will be seen in a moment. For now, let us con- 
centrate on how the keyword length can be determined. The important insight that leads 
to a solution is the following: If two identical sequences of plaintext letters occur at a dis- 
tance that is an integer multiple of the keyword length, they will generate identical 
ciphertext sequences. In the foregoing example, two instances of the sequence “red” are 
separated by nine character positions. Consequently, in both cases, r is encrypted using 
key letter e, e is encrypted using key letter p, and d is encrypted using key letter ¢. Thus, 
in both cases, the ciphertext sequence is VT W. We indicate this above by underlining the 
relevant ciphertext letters and shading the relevant ciphertext numbers. 

An analyst looking at only the ciphertext would detect the repeated sequences 
VTW at a displacement of 9 and make the assumption that the keyword is either 
three or nine letters in length. The appearance of VTW twice could be by chance 
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and not reflect identical plaintext letters encrypted with identical key letters. 
However, if the message is long enough, there will be a number of such repeated 
ciphertext sequences. By looking for common factors in the displacements of the 
various sequences, the analyst should be able to make a good guess of the keyword 
length. 

Solution of the cipher now depends on an important insight. If the keyword 
length is m, then the cipher, in effect, consists of m monoalphabetic substitution 
ciphers. For example, with the keyword DECEPTIVE, the letters in positions 1, 10, 
19, and so on are all encrypted with the same monoalphabetic cipher. Thus, we can 
use the known frequency characteristics of the plaintext language to attack each of 
the monoalphabetic ciphers separately. 

The periodic nature of the keyword can be eliminated by using a nonrepeating 
keyword that is as long as the message itself. Vigenére proposed what is referred to 
as an autokey system, in which a keyword is concatenated with the plaintext itself to 
provide a running key. For our example, 


key: deceptivewearediscoveredsav 
plaintext: wearediscoveredsaveyourself 
ciphertext: ZICVTWONGKZETIGASXSTSLVVWLA 


Even this scheme is vulnerable to cryptanalysis. Because the key and the plain- 
text share the same frequency distribution of letters, a statistical technique can be 
applied. For example, e enciphered by e, by Figure 2.5, can be expected to occur with a 
frequency of (0.127)? ~ 0.016, whereas t enciphered by ¢ would occur only about half 
as often. These regularities can be exploited to achieve successful cryptanalysis.® 


VERNAM CIPHER The ultimate defense against such a cryptanalysis is to choose a 
keyword that is as long as the plaintext and has no statistical relationship to it. Such 
a system was introduced by an AT&T engineer named Gilbert Vernam in 1918. His 
system works on binary data (bits) rather than letters. The system can be expressed 
succinctly as follows (Figure 2.7): 


Ci = Di ® k; 


Pp; = ith binary digit of plaintext 
k; = ith binary digit of key 
; = ith binary digit of ciphertext 


as) 
| 


@ =exclusive-or (XOR) operation 


Compare this with Equation (2.3) for the Vigenére cipher. 


SAlthough the techniques for breaking a Vigenére cipher are by no means complex, a 1917 issue of 
Scientific American characterized this system as “impossible of translation.” This is a point worth remem- 
bering when similar claims are made for modern algorithms. 
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Figure 2.7 Vernam Cipher 


Thus, the ciphertext is generated by performing the bitwise XOR of the plain- 
text and the key. Because of the properties of the XOR, decryption simply involves 
the same bitwise operation: 


Pi = 4 Ok; 


which compares with Equation (2.4). 

The essence of this technique is the means of construction of the key. 
Vernam proposed the use of a running loop of tape that eventually repeated the 
key, so that in fact the system worked with a very long but repeating keyword. 
Although such a scheme, with a long key, presents formidable cryptanalytic diffi- 
culties, it can be broken with sufficient ciphertext, the use of known or probable 
plaintext sequences, or both. 


One-Time Pad 


An Army Signal Corp officer, Joseph Mauborgne, proposed an improvement to the 
Vernam cipher that yields the ultimate in security. Mauborgne suggested using a 
random key that is as long as the message, so that the key need not be repeated. In 
addition, the key is to be used to encrypt and decrypt a single message, and then is 
discarded. Each new message requires a new key of the same length as the new mes- 
sage. Such a scheme, known as a one-time pad, is unbreakable. It produces random 
output that bears no statistical relationship to the plaintext. Because the ciphertext 
contains no information whatsoever about the plaintext, there is simply no way to 
break the code. 

An example should illustrate our point. Suppose that we are using a 
Vigenére scheme with 27 characters in which the twenty-seventh character is the 
space character, but with a one-time key that is as long as the message. Consider 
the ciphertext 


ANKYODKYUREPFJUBYOJDSPLREY IUNOFDOIUERFPLUYTS 


We now show two different decryptions using two different keys: 


ciphertext: ANKYODKYUREPFJBYOJDSPLREYIUNOFDOITUERFPLUYTS 
key: pximvmsydofuyrvzwce tnlebnecvgdupahfzzimnyih 
plaintext: mr mustard with the candlestick in the hall 
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ciphertext: ANKYODKYUREPFJBYOJDSPLREYIUNOFDOLIUERFPLUYTS 
key: mfugpmiydgaxgoufhkl1llmhsqdqogtewbqfgyovuhwt 
plaintext: miss scarlet with the knife in the library 


Suppose that a cryptanalyst had managed to find these two keys. Two plausible 
plaintexts are produced. How is the cryptanalyst to decide which is the correct 
decryption (i.e., which is the correct key)? If the actual key were produced in a truly 
random fashion, then the cryptanalyst cannot say that one of these two keys is more 
likely than the other. Thus, there is no way to decide which key is correct and there- 
fore which plaintext is correct. 

In fact, given any plaintext of equal length to the ciphertext, there is a key that 
produces that plaintext. Therefore, if you did an exhaustive search of all possible 
keys, you would end up with many legible plaintexts, with no way of knowing which 
was the intended plaintext. Therefore, the code is unbreakable. 

The security of the one-time pad is entirely due to the randomness of the key. 
If the stream of characters that constitute the key is truly random, then the stream of 
characters that constitute the ciphertext will be truly random. Thus, there are no 
patterns or regularities that a cryptanalyst can use to attack the ciphertext. 

In theory, we need look no further for a cipher. The one-time pad offers com- 
plete security but, in practice, has two fundamental difficulties: 


1. There is the practical problem of making large quantities of random keys. Any 
heavily used system might require millions of random characters on a regular 
basis. Supplying truly random characters in this volume is a significant task. 


n 


Even more daunting is the problem of key distribution and protection. For 
every message to be sent, a key of equal length is needed by both sender and 
receiver. Thus, a mammoth key distribution problem exists. 


Because of these difficulties, the one-time pad is of limited utility and is useful 
primarily for low-bandwidth channels requiring very high security. 

The one-time pad is the only cryptosystem that exhibits what is referred to as 
perfect secrecy. This concept is explored in Appendix F. 


2.3 TRANSPOSITION TECHNIQUES 


All the techniques examined so far involve the substitution of a ciphertext symbol 
for a plaintext symbol. A very different kind of mapping is achieved by performing 
some sort of permutation on the plaintext letters. This technique is referred to as a 
transposition cipher. 

The simplest such cipher is the rail fence technique, in which the plaintext is 
written down as a sequence of diagonals and then read off as a sequence of rows. For 
example, to encipher the message “meet me after the toga party” with a rail fence of 
depth 2, we write the following: 


mematrhtgopry 
etefeteoaat 
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The encrypted message is 
MEMATRHTGPRYETEFETEOAAT 


This sort of thing would be trivial to cryptanalyze. A more complex scheme is 
to write the message in a rectangle, row by row, and read the message off, column by 
column, but permute the order of the columns. The order of the columns then 
becomes the key to the algorithm. For example, 


Key: 43° 225 607 
Plaintext: attackop 
ostpone 
dun ta. 1 t 
woamxyaz 
Ciphertext: TTNAAPTMTSUOAODWCOLXKNLY PETZ 


Thus, in this example, the key is 4312567. To encrypt, start with the column that 
is labeled 1, in this case column 3. Write down all the letters in that column. Proceed to 
column 4, which is labeled 2, then column 2, then column 1, then columns 5, 6, and 7. 

A pure transposition cipher is easily recognized because it has the same letter 
frequencies as the original plaintext. For the type of columnar transposition just 
shown, cryptanalysis is fairly straightforward and involves laying out the ciphertext in 
a matrix and playing around with column positions. Digram and trigram frequency 
tables can be useful. 

The transposition cipher can be made significantly more secure by performing 
more than one stage of transposition. The result is a more complex permutation that 
is not easily reconstructed. Thus, if the foregoing message is reencrypted using the 
same algorithm, 


Key: A. 3) al 4255 6: 27 

Input: ttnaapt 
mtsuoao 
dwcoixk 
niypetaz 

Output: NSCYAUOPTTWLTMDNAOTEPAXTTOKZ 


To visualize the result of this double transposition, designate the letters in 
the original plaintext message by the numbers designating their position. Thus, 
with 28 letters in the message, the original sequence of letters is 


01 02 03 04 05 06 07 08 09 10 11 12 13 14 
15 16 17 18 19 20 21 22 23 24 25 26 27 28 


After the first transposition, we have 


03 10 17 24 04 11 18 25 02 09 16 23 01 08 
15 22 05 12 19 26 06 13 20 27 07 14 21 28 
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which has a somewhat regular structure. But after the second transposition, we have 


17 09 05 27 24 16 12 07 10 02 22 20 03 25 
15 13 04 23 19 14 11 01 26 21 18 08 06 28 


This is a much less structured permutation and is much more difficult to cryptanalyze. 


2.4 ROTOR MACHINES 


The example just given suggests that multiple stages of encryption can produce an 
algorithm that is significantly more difficult to cryptanalyze. This is as true of substi- 
tution ciphers as it is of transposition ciphers. Before the introduction of DES, the 
most important application of the principle of multiple stages of encryption was a 
class of systems known as rotor machines.” 

The basic principle of the rotor machine is illustrated in Figure 2.8. The 
machine consists of a set of independently rotating cylinders through which electri- 
cal pulses can flow. Each cylinder has 26 input pins and 26 output pins, with internal 
wiring that connects each input pin to a unique output pin. For simplicity, only three 
of the internal connections in each cylinder are shown. 

If we associate each input and output pin with a letter of the alphabet, then a 
single cylinder defines a monoalphabetic substitution. For example, in Figure 2.8, 
if an operator depresses the key for the letter A, an electric signal is applied to the 
first pin of the first cylinder and flows through the internal connection to the 
twenty-fifth output pin. 

Consider a machine with a single cylinder. After each input key is depressed, the 
cylinder rotates one position, so that the internal connections are shifted accordingly. 
Thus, a different monoalphabetic substitution cipher is defined. After 26 letters of 
plaintext, the cylinder would be back to the initial position. Thus, we have a poly- 
alphabetic substitution algorithm with a period of 26. 

A single-cylinder system is trivial and does not present a formidable cryptana- 
lytic task. The power of the rotor machine is in the use of multiple cylinders, in which 
the output pins of one cylinder are connected to the input pins of the next. Figure 2.8 
shows a three-cylinder system. The left half of the figure shows a position in which the 
input from the operator to the first pin (plaintext letter a) is routed through the three 
cylinders to appear at the output of the second pin (ciphertext letter B). 

With multiple cylinders, the one closest to the operator input rotates one pin 
position with each keystroke. The right half of Figure 2.8 shows the system’s config- 
uration after a single keystroke. For every complete rotation of the inner cylinder, 
the middle cylinder rotates one pin position. Finally, for every complete rotation 
of the middle cylinder, the outer cylinder rotates one pin position. This is the 
same type of operation seen with an odometer. The result is that there are 
26 X 26 X 26 = 17,576 different substitution alphabets used before the system 


°Machines based on the rotor principle were used by both Germany (Enigma) and Japan (Purple) 
in World War II. The breaking of both codes by the Allies was a significant factor in the war’s outcome. 
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Figure 2.8 Three-Rotor Machine with Wiring Represented by Numbered Contacts 
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repeats. The addition of fourth and fifth rotors results in periods of 456,976 
and 11,881,376 letters, respectively. As David Kahn eloquently put it, referring to a 
five-rotor machine [KAHN96, page 413]: 


A period of that length thwarts any practical possibility of a 
straightforward solution on the basis of letter frequency. This 
general solution would need about 50 letters per cipher alphabet, 
meaning that all five rotors would have to go through their com- 
bined cycle 50 times. The ciphertext would have to be as long as 
all the speeches made on the floor of the Senate and the House 
of Representatives in three successive sessions of Congress. No 
cryptanalyst is likely to bag that kind of trophy in his lifetime; 
even diplomats, who can be as verbose as politicians, rarely scale 
those heights of loquacity. 


The significance of the rotor machine today is that it points the way to the most 
widely used cipher ever: the Data Encryption Standard (DES). This we examine in 
Chapter 3. 


2.5 STEGANOGRAPHY 


We conclude with a discussion of a technique that (strictly speaking), is not encryp- 
tion, namely, steganography. 

A plaintext message may be hidden in one of two ways. The methods of 
steganography conceal the existence of the message, whereas the methods of cryp- 
tography render the message unintelligible to outsiders by various transformations 
of the text.!° 

A simple form of steganography, but one that is time-consuming to construct, 
is one in which an arrangement of words or letters within an apparently innocuous 
text spells out the real message. For example, the sequence of first letters of each 
word of the overall message spells out the hidden message. Figure 2.9 shows an 
example in which a subset of the words of the overall message is used to convey the 
hidden message. See if you can decipher this; it’s not too hard. 

Various other techniques have been used historically; some examples are the 
following [MYER91]: 


e Character marking: Selected letters of printed or typewritten text are over- 
written in pencil. The marks are ordinarily not visible unless the paper is held 
at an angle to bright light. 


e Invisible ink: A number of substances can be used for writing but leave no 
visible trace until heat or some chemical is applied to the paper. 


10 Steganography was an obsolete word that was revived by David Kahn and given the meaning it has 
today [KAHN96]. 
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3rd March 
Dear George, 


Greetings +o all at Oxford. Many thanks for your 
letter and for the Summer examination package. 
All Entry Forms and Fees Forms should be ready 
for final despatch to the Syndicate by Friday 
20th or at the very latest, itm told. by the 21st 


Admin has improved here, though therets room 

for improvements still; just give us all two or three 
more years and well really show you! Please 
don't (et these wretched 16+ proposals destroy 
your basic O andA pattern. Certainly this 

sort of Change, if implemented immediately, 

would bring chaos. 


Sincerely yours. 


Figure 2.9 A Puzzle for Inspector Morse 
(From The Silent World of Nicholas Quinn, by Colin Dexter) 


e Pin punctures: Small pin punctures on selected letters are ordinarily not visi- 
ble unless the paper is held up in front of a light. 


e Typewriter correction ribbon: Used between lines typed with a black ribbon, the 
results of typing with the correction tape are visible only under a strong light. 


Although these techniques may seem archaic, they have contemporary equiv- 
alents. [(WAYN93] proposes hiding a message by using the least significant bits of 
frames on a CD. For example, the Kodak Photo CD format’s maximum resolution is 
2048 X 3072 pixels, with each pixel containing 24 bits of RGB color information. The 
least significant bit of each 24-bit pixel can be changed without greatly affecting the 
quality of the image. The result is that you can hide a 2.3-megabyte message in a 
single digital snapshot. There are now a number of software packages available that 
take this type of approach to steganography. 

Steganography has a number of drawbacks when compared to encryption. It 
requires a lot of overhead to hide a relatively few bits of information, although using a 
scheme like that proposed in the preceding paragraph may make it more effective. Also, 
once the system is discovered, it becomes virtually worthless. This problem, too, can be 
overcome if the insertion method depends on some sort of key (e.g., see Problem 2.20). 
Alternatively, a message can be first encrypted and then hidden using steganography. 

The advantage of steganography is that it can be employed by parties who 
have something to lose should the fact of their secret communication (not necessar- 
ily the content) be discovered. Encryption flags traffic as important or secret or may 
identify the sender or receiver as someone with something to hide. 
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2.6 RECOMMENDED READING AND WEB SITES 


For anyone interested in the history of code making and code breaking, the book to read is 
[KAHN96]. Although it is concerned more with the impact of cryptology than its technical 
development, it is an excellent introduction and makes for exciting reading. Another excel- 
lent historical account is [SING99]. 

A short treatment covering the techniques of this chapter, and more, is [GARD72]. 
There are many books that cover classical cryptography in a more technical vein; one of the 
best is [SINK66]. [KORN96] is a delightful book to read and contains a lengthy section on 
classical techniques. Two cryptography books that contain a fair amount of technical material 
on classical techniques are [GARRO1] and [NICH99]. For the truly interested reader, the 
two-volume [NICH96] covers numerous classical ciphers in detail and provides many cipher- 
texts to be cryptanalyzed, together with the solutions. 

An excellent treatment of rotor machines, including a discussion of their cryptanalysis 
is found in [KUMA97]. 

[KATZ00] provides a thorough treatment of steganography. Another good source is 
[WAYN96]. 


GARD72_ Gardner, M. Codes, Ciphers, and Secret Writing. New York: Dover, 1972. 

GARRO1_ Garrett, P. Making, Breaking Codes: An Introduction to Cryptology. Upper 
Saddle River, NJ: Prentice Hall, 2001. 

KAHN96_ Kahn, D. The Codebreakers: The Story of Secret Writing. New York: Scribner, 
1996. 

KATZ00_ Katzenbeisser, S., ed. Information Hiding Techniques for Steganography and 
Digital Watermarking. Boston: Artech House, 2000. 

KORN96_ Korner, T. The Pleasures of Counting. Cambridge, England: Cambridge 
University Press, 1996. 


KUMA97_ Kumar, I. Cryptology. Laguna Hills, CA: Aegean Park Press, 1997. 


NICH96 Nichols, R. Classical Cryptography Course. Laguna Hills, CA: Aegean Park 
Press, 1996. 


NICH99 Nichols, R., ed. [CSA Guide to Cryptography. New York: McGraw-Hill, 1999. 


SING99_ Singh, S. The Code Book: The Science of Secrecy from Ancient Egypt to 
Quantum Cryptography. New York: Anchor Books, 1999. 


SINK66_ Sinkov, A. Elementary Cryptanalysis: A Mathematical Approach. Washington, 
D.C.: The Mathematical Association of America, 1966. 


WAYN96 Wayner, P. Disappearing Cryptography. Boston: AP Professional Books, 1996. 


Recommended Web Sites: 


e American Cryptogram Association: An association of amateur cryptographers. 
The Web site includes information and links to sites concerned with classical 


cryptography. 
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e Crypto Corner: Simon Singh’s Web site. Lots of good information, plus interactive tools 
for learning about cryptography. 


e Steganography: Good collection of links and documents. 


2.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


block cipher cryptology Playfair cipher 
brute-force attack deciphering polyalphabetic cipher 
Caesar cipher decryption rail fence cipher 
cipher digram single-key encryption 
ciphertext enciphering steganography 
computationally secure encryption stream cipher 
conventional encryption Hill cipher symmetric encryption 
cryptanalysis monoalphabetic cipher transposition cipher 
cryptographic system one-time pad unconditionally secure 
cryptography plaintext Vigenére cipher 


Review Questions 


2.1 What are the essential ingredients of a symmetric cipher? 

2.2 What are the two basic functions used in encryption algorithms? 

2.3 How many keys are required for two people to communicate via a cipher? 

2.4 What is the difference between a block cipher and a stream cipher? 

2.5 What are the two general approaches to attacking a cipher? 

2.6 List and briefly define types of cryptanalytic attacks based on what is known to the 


attacker. 


2.7 What is the difference between an unconditionally secure cipher and a computation- 
ally secure cipher? 


2.8 Briefly define the Caesar cipher. 
2.9 Briefly define the monoalphabetic cipher. 
2.10 Briefly define the Playfair cipher. 
2.11 What is the difference between a monoalphabetic cipher and a polyalphabetic 
cipher? 
2.12 What are two problems with the one-time pad? 
2.13. What is a transposition cipher? 
2.14 What is steganography? 


Problems 


2.1 A generalization of the Caesar cipher, known as the affine Caesar cipher, has the 
following form: For each plaintext letter p, substitute the ciphertext letter C: 


C = E({a, b], p) = (ap + b) mod 26 


t ~) 
mn 


2.6 
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A basic requirement of any encryption algorithm is that it be one-to-one. That is, if 

p # q, then E(k, p) 4 E(k, gq). Otherwise, decryption is impossible, because more 

than one plaintext character maps into the same ciphertext character. The affine 

Caesar cipher is not one-to-one for all values of a. For example, for a = 2 and b = 3, 

then E([a, b], 0) = E({a, b], 13) = 3. 

a. Are there any limitations on the value of b? Explain why or why not. 

b. Determine which values of a are not allowed. 

c. Provide a general statement of which values of a are and are not allowed. Justify 
your statement. 

How many one-to-one affine Caesar ciphers are there? 

A ciphertext has been generated with an affine cipher. The most frequent letter of the 

ciphertext is ‘B’, and the second most frequent letter of the ciphertext is ‘U’. Break 

this code. 


The following ciphertext was generated using a simple substitution algorithm. 


53441305) )6*;4826)4+.)4+) ;806*; 4818960) )85;;18*;:+*8t83 
(88)5*t;46(;88*96*?;8) *+(;485) ;5*t2:*4¢(;4956*2 (5*—4) 898* 
74069285) ;)6+t8)444#;1(49;48081;8:841;48185;4) 4851t528806*81 
(+9;48; (88;4(4+?34;48) 4+;161; :188;+4?; 


Decrypt this message. 

Hints: 

1. As you know, the most frequently occurring letter in English is e. Therefore, the 
first or second (or perhaps third?) most common character in the message is likely 
to stand for e. Also, e is often seen in pairs (e.g., meet, fleet, speed, seen, been, 
agree, etc.). Try to find a character in the ciphertext that decodes to e. 

2. The most common word in English is “the.” Use this fact to guess the characters 
that stand for t and h. 

3. Decipher the rest of the message by deducing additional words. 

Warning: The resulting message is in English but may not make much sense on a first 

reading. 

One way to solve the key distribution problem is to use a line from a book that both 

the sender and the receiver possess. Typically, at least in spy novels, the first sentence 

of a book serves as the key. The particular scheme discussed in this problem is from 
one of the best suspense novels involving secret codes, Talking to Strange Men, by 

Ruth Rendell. Work this problem without consulting that book! 


Consider the following message: 
SIDKHKDM AF HCRKIABIE SHIMC KD LFEAILA 


This ciphertext was produced using the first sentence of The Other Side of Silence 
(a book about the spy Kim Philby): 


The snow lay thick on the steps and the snowflakes driven by the wind 
looked black in the headlights of the cars. 


A simple substitution cipher was used. 

a. What is the encryption algorithm? 

b. How secure is it? 

c. To make the key distribution problem simple, both parties can agree to use the 
first or last sentence of a book as the key. To change the key, they simply need to 
agree on a new book. The use of the first sentence would be preferable to the use 
of the last. Why? 


In one of his cases, Sherlock Holmes was confronted with the following message. 


534 C2 13 127 36 31 4 17 21 41 
DOUGLAS 109 293 5 37 BIRLSTONE 
26 BIRLSTONE 9 127 171 
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2.9 


2.10 


Although Watson was puzzled, Holmes was able immediately to deduce the type of 

cipher. Can you? 

This problem uses a real-world example, from an old U.S. Special Forces manual (public 

domain). A copy is available at this book’s Web site. 

a. Using the two keys (memory words) cryptographic and network security, encrypt 
the following message: 


Be at the third pillar from the left outside the lyceum theatre tonight at seven. 
If you are distrustful bring two friends. 


Make reasonable assumptions about how to treat redundant letters and excess 
letters in the memory words and how to treat spaces and punctuation. Indicate 
what your assumptions are. Note: The message is from the Sherlock Holmes 
novel, The Sign of Four. 
b. Decrypt the ciphertext. Show your work. 
c. Comment on when it would be appropriate to use this technique and what its 
advantages are. 
A disadvantage of the general monoalphabetic cipher is that both sender and 
receiver must commit the permuted cipher sequence to memory. A common tech- 
nique for avoiding this is to use a keyword from which the cipher sequence can be 
generated. For example, using the keyword CIPHER, write out the keyword 
followed by unused letters in normal order and match this against the plaintext 
letters: 


d 
H 


Ho 


c fghijgkimnopaqrstuvwxyaz 
P RABDFGJIJIKLUMNOQS TUVWXYZ 


If it is felt that this process does not produce sufficient mixing, write the remaining 
letters on successive lines and then generate the sequence by reading down the 
columns: 


KUNA PO 
NHtWH 
qs ut 
q2 00 
Soon 
“x10 4 


This yields the sequence: 
CAKSYIBLT2ZPDMUHFNVEGOWRIJIQX 


I 


Such a system is used in the example in Section 2.2 (the one that begins “it was dis- 
closed yesterday”). Determine the keyword. 

When the PT-109 American patrol boat, under the command of Lieutenant John F. 
Kennedy, was sunk by a Japanese destroyer, a message was received at an Australian 
wireless station in Playfair code: 


Y UREBE ZWEHE WRYTU HEYFS 
E GOYFI WTTTU OLKSY CAJPO 
BOTEI ZONTX BYBNT GONEY CUZWR 
GDSON SXBOU YWRHE BAAHY USEDQ 


The key used was royal new zealand navy. Decrypt the message. Translate TT 

into tt. 

a. Construct a Playfair matrix with the key largest. 

b. Construct a Playfair matrix with the key occurrence. Make a reasonable assump- 
tion about how to treat redundant letters in the key. 


2.11 


n 
—_ 
i) 


NN 
—_ jm 
& Uo 


Nn 
—_ 
mn 


2.16 


2.7 / KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 63 


a. Using this Playfair matrix: 


M PE H I/J K 
U N O P Q 
Z Vv W x Y 
E L A R G 
D S T B C 


Encrypt this message: 
Must see you over Cadogan West. Coming at once. 


Note: The message is from the Sherlock Holmes story, The Adventure of the Bruce- 

Partington Plans. 

b. Repeat part (a) using the Playfair matrix from Problem 2.10a. 

c. How do you account for the results of this problem? Can you generalize your 
conclusion? 


a. How many possible keys does the Playfair cipher have? Ignore the fact that some 
keys might produce identical encryption results. Express your answer as an 
approximate power of 2. 

b. Now take into account the fact that some Playfair keys produce the same encryp- 
tion results. How many effectively unique keys does the Playfair cipher have? 


What substitution system results when we use a 25 x | Playfair matrix? 
a. Encrypt the message “meet me at the usual place at ten rather than eight oclock” 


4 
using the Hill cipher with the key @ *). Show your calculations and the result. 


b. Show the calculations for the corresponding decryption of the ciphertext to 
recover the original plaintext. 


We have shown that the Hill cipher succumbs to a known plaintext attack if sufficient 
plaintext-ciphertext pairs are provided. It is even easier to solve the Hill cipher if a 
chosen plaintext attack can be mounted. Describe such an attack. 


: requires that (ad — bc) 

is relatively prime to 26; that is, the only common positive integer factor of (ad — bc) 

and 26 is 1. Thus, if (ad — bc) = 13 or is even, the matrix is not allowed. Determine 

the number of different (good) keys there are for a 2 x 2 Hill cipher without counting 

them one by one, using the following steps: 

a. Find the number of matrices whose determinant is even because one or both rows 
are even. (A row is “even” if both entries in the row are even.) 

b. Find the number of matrices whose determinant is even because one or both 
columns are even. (A column is “even” if both entries in the column are even.) 

c. Find the number of matrices whose determinant is even because all of the entries 
are odd. 

d. Taking into account overlaps, find the total number of matrices whose determi- 
nant is even. 

e. Find the number of matrices whose determinant is a multiple of 13 because the 
first column is a multiple of 13. 

f. Find the number of matrices whose determinant is a multiple of 13 where the 

first column is not a multiple of 13 but the second column is a multiple of the first 

modulo 13. 

Find the total number of matrices whose determinant is a multiple of 13. 

Find the number of matrices whose determinant is a multiple of 26 because they 

fit cases parts (a) and (e), (b) and (e), (c) and (e), (a) and (f), and so on. 

i. Find the total number of matrices whose determinant is neither a multiple of 2 nor 
a multiple of 13. 


It can be shown that the Hill cipher with the matrix ¢ 
c 


Po 
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Using the Vigenére cipher, encrypt the word “explanation” using the key /eg. 
This problem explores the use of a one-time pad version of the Vigenére cipher. In 
this scheme, the key is a stream of random numbers between 0 and 26. For example, if 
the key is 3 195..., then the first letter of plaintext is encrypted with a shift of 3 letters, 
the second with a shift of 19 letters, the third with a shift of 5 letters, and so on. 
a. Encrypt the plaintext sendmoremoney with the key stream 
9017 23 15 21 1411112 8 9 
b. Using the ciphertext produced in part (a), find a key so that the cipher text 
decrypts to the plaintext cashnotneeded. 

What is the message embedded in Figure 2.9? 
In one of Dorothy Sayers’s mysteries, Lord Peter is confronted with the message 
shown in Figure 2.10. He also discovers the key to the message, which is a sequence of 
integers: 

787656543432112343456567878878765654 

3432112343456567878878765654433211234 


a. Decrypt the message. Hint: What is the largest integer value? 
b. Ifthe algorithm is known but not the key, how secure is the scheme? 
c. Ifthe key is known but not the algorithm, how secure is the scheme? 


Programming Problems 
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Write a program that can encrypt and decrypt using the general Caesar cipher, also 
known as an additive cipher. 


Write a program that can encrypt and decrypt using the affine cipher described in 
Problem 2.1. 


| thought to see the fairies in the 
fields, but | saw only the evil elephants 
with their black packs. Woe! how that 
sight awed me! The elves danced all 
around and about while / heard voices 
calling clearly. Ah! how | tried to 
see-throw off the ugly cloud-but no blind 
eve of a Mortal was permitted to spy 
them So then came minstrels, having gold 
trumpets, harps and drums. These played 
very loudly beside me, breaking that spell. 
So the dream vanished, whereat | thanked 
Heaven. | shed many tears before the thin 
moon rose Up, frail and faint as a sickle of 
straw. Now though the Enchanter gnash 
his teeth vainly, yet shall he return as the 
Spring returns. Oh, wretched man! Hell 
gapes, Erebus now lies open. The Mouths 
of Death wait on thy end. 


Figure 2.10 A Puzzle for Lord Peter 
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Write a program that can perform a letter frequency attack on an additive cipher 
without human intervention. Your software should produce possible plaintexts in 
rough order of likelihood. It would be good if your user interface allowed the user to 
specify “give me the top 10 possible plaintexts.” 

Write a program that can perform a letter frequency attack on any monoalphabetic 
substitution cipher without human intervention. Your software should produce possi- 
ble plaintexts in rough order of likelihood. It would be good if your user interface 
allowed the user to specify “give me the top 10 possible plaintexts.” 

Create software that can encrypt and decrypt using a 2 x 2 Hill cipher. 


Create software that can perform a fast known plaintext attack on a Hill cipher, given 
the dimension m. How fast are your algorithms, as a function of m? 


BLOCK CIPHERS AND THE DATA 
ENCRYPTION STANDARD 


3.1 Block Cipher Principles 


Stream Ciphers and Block Ciphers 
Motivation for the Feistel Cipher Structure 
The Feistel Cipher 


3.2. The Data Encryption Standard 


DES Encryption 
DES Decryption 


3.3 A Des Example 


Results 
The Avalanche Effect 


3.4 The Strength of Des 


The Use of 56-Bit Keys 
The Nature of the DES Algorithm 
Timing Attacks 


3.5 Differential and Linear Cryptanalysis 


Differential Cryptanalysis 
Linear Cryptanalysis 


3.6 Block Cipher Design Principles 


DES Design Criteria 
Number of Rounds 
Design of Function F 
Key Schedule Algorithm 


3.7 Recommended Reading and Web Site 


3.8 Key Terms, Review Questions, and Problems 


66 


3.1 / BLOCK CIPHER PRINCIPLES 67 


All the afternoon Mungo had been working on Stern’s code, principally with the 
aid of the latest messages which he had copied down at the Nevin Square drop. 
Stern was very confident. He must be well aware London Central knew about 
that drop. It was obvious that they didn’t care how often Mungo read their 
messages, so confident were they in the impenetrability of the code. 


—Talking to Strange Men, Ruth Rendell 


KEY POINTS 


© A block cipher is an encryption/decryption scheme in which a block of 
plaintext is treated as a whole and used to produce a ciphertext block of 
equal length. 


® Many block ciphers have a Feistel structure. Such a structure consists of a 
number of identical rounds of processing. In each round, a substitution is 
performed on one half of the data being processed, followed by a permu- 
tation that interchanges the two halves. The original key is expanded so 
that a different key is used for each round. 


® The Data Encryption Standard (DES) has been the most widely used 
encryption algorithm until recently. It exhibits the classic Feistel structure. 
DES uses a 64-bit block and a 56-bit key. 

© ‘Two important methods of cryptanalysis are differential cryptanalysis and 
linear cryptanalysis. DES has been shown to be highly resistant to these two 
types of attack. 


The objective of this chapter is to illustrate the principles of modern symmetric 
ciphers. For this purpose, we focus on the most widely used symmetric cipher: the 
Data Encryption Standard (DES). Although numerous symmetric ciphers have been 
developed since the introduction of DES, and although it is destined to be replaced by 
the Advanced Encryption Standard (AES), DES remains the most important such 
algorithm. Furthermore, a detailed study of DES provides an understanding of the 
principles used in other symmetric ciphers. 

This chapter begins with a discussion of the general principles of symmetric 
block ciphers, which are the type of symmetric ciphers studied in this book (with the 
exception of the stream cipher RC4 in Chapter 7). Next, we cover full DES. 
Following this look at a specific algorithm, we return to a more general discussion of 
block cipher design. 

Compared to public-key ciphers, such as RSA, the structure of DES and most 
symmetric ciphers is very complex and cannot be explained as easily as RSA and simi- 
lar algorithms. Accordingly, the reader may wish to begin with a simplified version of 
DES, which is described in Appendix G. This version allows the reader to perform 
encryption and decryption by hand and gain a good understanding of the working of 
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the algorithm details. Classroom experience indicates that a study of this simplified 
version enhances understanding of DES.! 


3.1 BLOCK CIPHER PRINCIPLES 


Many symmetric block encryption algorithms in current use are based on a struc- 
ture referred to as a Feistel block cipher [FEIS73]. For that reason, it is important to 
examine the design principles of the Feistel cipher. We begin with a comparison of 
stream ciphers and block ciphers. Then we discuss the motivation for the Feistel 
block cipher structure. Finally, we discuss some of its implications. 


Stream Ciphers and Block Ciphers 


A stream cipher is one that encrypts a digital data stream one bit or one byte at a time. 
Examples of classical stream ciphers are the autokeyed Vigenére cipher and the 
Vernam cipher. In the ideal case, a one-time pad version of the Vernam cipher would 
be used (Figure 2.7), in which the keystream (k;) is as long as the plaintext bit stream 
(p;). If the cryptographic keystream is random, then this cipher is unbreakable by any 
means other than acquiring the keystream. However, the keystream must be provided 
to both users in advance via some independent and secure channel. This introduces 
insurmountable logistical problems if the intended data traffic is very large. 

Accordingly, for practical reasons, the bit-stream generator must be imple- 
mented as an algorithmic procedure, so that the cryptographic bit stream can be 
produced by both users. In this approach (Figure 3.1a), the bit-stream generator is a 
key-controlled algorithm and must produce a bit stream that is cryptographically 
strong. Now, the two users need only share the generating key, and each can produce 
the keystream. 

A block cipher is one in which a block of plaintext is treated as a whole and 
used to produce a ciphertext block of equal length. Typically, a block size of 64 or 
128 bits is used. As with a stream cipher, the two users share a symmetric encryption 
key (Figure 3.1b). Using some of the modes of operation explained in Chapter 6, a 
block cipher can be used to achieve the same effect as a stream cipher. 

Far more effort has gone into analyzing block ciphers. In general, they seem 
applicable to a broader range of applications than stream ciphers. The vast majority 
of network-based symmetric cryptographic applications make use of block ciphers. 
Accordingly, the concern in this chapter, and in our discussions throughout the book 
of symmetric encryption, will primarily focus on block ciphers. 


Motivation for the Feistel Cipher Structure 


A block cipher operates on a plaintext block of n bits to produce a ciphertext 
block of n bits. There are 2” possible different plaintext blocks and, for 
the encryption to be reversible (i.e., for decryption to be possible), each must 


"However, you may safely skip Appendix G, at least on a first reading. If you get lost or bogged down in 
the details of DES, then you can go back and start with simplified DES. 
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Figure 3.1 Stream Cipher and Block Cipher 


produce a unique ciphertext block. Such a transformation is called reversible, or 
nonsingular. The following examples illustrate nonsingular and singular transfor- 
mations for n = 2. 


Reversible Mapping Irreversible Mapping 
Plaintext Ciphertext Plaintext Ciphertext 
00 11 00 11 
01 10 01 10 
10 00 10 01 
11 01 11 01 


In the latter case, a ciphertext of 01 could have been produced by one of two plain- 
text blocks. So if we limit ourselves to reversible mappings, the number of different 
transformations is 2”!. 

Figure 3.2 illustrates the logic of a general substitution cipher for n = 4. 
A 4-bit input produces one of 16 possible input states, which is mapped by the 
substitution cipher into a unique one of 16 possible output states, each of which is 
represented by 4 ciphertext bits. The encryption and decryption mappings can be 


The reasoning is as follows: For the first plaintext, we can choose any of 2” ciphertext blocks. For the 
second plaintext, we choose from among 2” — 1 remaining ciphertext blocks, and so on. 
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Figure 3.2. General n-bit-n-bit Block Substitution (shown with n = 4) 


defined by a tabulation, as shown in Table 3.1. This is the most general form of block 
cipher and can be used to define any reversible mapping between plaintext and 
ciphertext. Feistel refers to this as the ideal block cipher, because it allows for the max- 
imum number of possible encryption mappings from the plaintext block [FEIS75]. 


Table 3.1 Encryption and Decryption Tables for Substitution 
Cipher of Figure 3.2 


Plaintext Ciphertext Ciphertext Plaintext 


0000 1110 0000 1110 
0001 0100 0001 0011 
0010 1101 0010 0100 
0011 0001 0011 1000 
0100 0010 0100 0001 
0101 1111 0101 1100 
0110 1011 0110 1010 
0111 1000 0111 ala 
1000 0011 1000 0111 
1001 1010 1001 1101 
1010 0110 1010 1001 
1011 1100 1011 0110 
1100 0101 1100 1011 
1101 1001 1101 0010 
1110 0000 1110 0000 
1111 0111 itil 0101 


3.1 / BLOCK CIPHER PRINCIPLES 71 


But there is a practical problem with the ideal block cipher. If a small block 
size, such as n = 4, is used, then the system is equivalent to a classical substitution 
cipher. Such systems, as we have seen, are vulnerable to a statistical analysis of the 
plaintext. This weakness is not inherent in the use of a substitution cipher but 
rather results from the use of a small block size. If n is sufficiently large and an 
arbitrary reversible substitution between plaintext and ciphertext is allowed, then 
the statistical characteristics of the source plaintext are masked to such an extent 
that this type of cryptanalysis is infeasible. 

An arbitrary reversible substitution cipher (the ideal block cipher) for a large 
block size is not practical, however, from an implementation and performance point 
of view. For such a transformation, the mapping itself constitutes the key. Consider 
again Table 3.1, which defines one particular reversible mapping from plaintext to 
ciphertext for n = 4. The mapping can be defined by the entries in the second 
column, which show the value of the ciphertext for each plaintext block. This, in 
essence, is the key that determines the specific mapping from among all possible 
mappings. In this case, using this straightforward method of defining the key, the 
required key length is (4 bits) X (16 rows) = 64 bits. In general, for an n-bit ideal 
block cipher, the length of the key defined in this fashion is n X 2” bits. For a 64-bit 
block, which is a desirable length to thwart statistical attacks, the required key 
length is 64 x 2% = 2” = 107! bits. 

In considering these difficulties, Feistel points out that what is needed is an 
approximation to the ideal block cipher system for large n, built up out of compo- 
nents that are easily realizable [FEIS75]. But before turning to Feistel’s approach, 
let us make one other observation. We could use the general block substitution 
cipher but, to make its implementation tractable, confine ourselves to a subset of the 
2"! possible reversible mappings. For example, suppose we define the mapping in 
terms of a set of linear equations. In the case of n = 4, we have 


Yr = Kye, + Kyoxg + ky3x3 + ky4xq 
V2 = Kayx1 + Kayxq + ko3x3 + Kogrg 
y3 = K3px1 + k3yxX_ + k33x3 + k3qrq 
Yq = KayXy + KagnxXy + kaggxzg + KggXq 


where the x; are the four binary digits of the plaintext block, the y; are the four 
binary digits of the ciphertext block, the i are the binary coefficients, and arith- 
metic is mod 2. The key size is just n’, in this case 16 bits. The danger with this 
kind of formulation is that it may be vulnerable to cryptanalysis by an attacker 
that is aware of the structure of the algorithm. In this example, what we have is 
essentially the Hill cipher discussed in Chapter 2, applied to binary data rather 
than characters. As we saw in Chapter 2, a simple linear system such as this is 
quite vulnerable. 


The Feistel Cipher 


Feistel proposed [FEIS73] that we can approximate the ideal block cipher by utilizing 
the concept of a product cipher, which is the execution of two or more simple ciphers 
in sequence in such a way that the final result or product is cryptographically stronger 
than any of the component ciphers. The essence of the approach is to develop a block 
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cipher with a key length of k bits and a block length of n bits, allowing a total of 2* 
possible transformations, rather than the 2”! transformations available with the ideal 
block cipher. 

In particular, Feistel proposed the use of a cipher that alternates substitutions 
and permutations, where these terms are defined as follows: 


e Substitution: Each plaintext element or group of elements is uniquely 
replaced by a corresponding ciphertext element or group of elements. 


e Permutation: A sequence of plaintext elements is replaced by a permutation 
of that sequence. That is, no elements are added or deleted or replaced in the 
sequence, rather the order in which the elements appear in the sequence is 
changed. 


In fact, Feistel’s is a practical application of a proposal by Claude Shannon to 
develop a product cipher that alternates confusion and diffusion functions 
[SHAN49].° We look next at these concepts of diffusion and confusion and then 
present the Feistel cipher. But first, it is worth commenting on this remarkable fact: 
The Feistel cipher structure, which dates back over a quarter century and which, in 
turn, is based on Shannon’s proposal of 1945, is the structure used by many signifi- 
cant symmetric block ciphers currently in use. 


DIFFUSION AND CONFUSION The terms diffusion and confusion were introduced by 
Claude Shannon to capture the two basic building blocks for any cryptographic 
system [SHAN49]. Shannon’s concern was to thwart cryptanalysis based on 
statistical analysis. The reasoning is as follows. Assume the attacker has some 
knowledge of the statistical characteristics of the plaintext. For example, in a 
human-readable message in some language, the frequency distribution of the 
various letters may be known. Or there may be words or phrases likely to appear in 
the message (probable words). If these statistics are in any way reflected in the 
ciphertext, the cryptanalyst may be able to deduce the encryption key, part of the 
key, or at least a set of keys likely to contain the exact key. In what Shannon refers 
to as a strongly ideal cipher, all statistics of the ciphertext are independent of the 
particular key used. The arbitrary substitution cipher that we discussed previously 
(Figure 3.2) is such a cipher, but as we have seen, it is impractical.‘ 

Other than recourse to ideal systems, Shannon suggests two methods for frus- 
trating statistical cryptanalysis: diffusion and confusion. In diffusion, the statistical 
structure of the plaintext is dissipated into long-range statistics of the ciphertext. 
This is achieved by having each plaintext digit affect the value of many ciphertext 
digits; generally, this is equivalent to having each ciphertext digit be affected by 


3The paper is available at this book’s Web site. Shannon’s 1949 paper appeared originally as a classified 
report in 1945. Shannon enjoys an amazing and unique position in the history of computer and informa- 
tion science. He not only developed the seminal ideas of modern cryptography but is also responsible for 
inventing the discipline of information theory. Based on his work in information theory, he developed a 
formula for the capacity of a data communications channel, which is still used today. In addition, he 
founded another discipline, the application of Boolean algebra to the study of digital circuits; this last he 
managed to toss off as a master’s thesis. 

4A ppendix F expands on Shannon’s concepts concerning measures of secrecy and the security of 
cryptographic algorithms. 
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many plaintext digits. An example of diffusion is to encrypt a message 
M = m,, mo, m3, ... of characters with an averaging operation: 


k 
a ( Smy:s) mod 26 
i=1 


adding k successive letters to get a ciphertext letter y,,. One can show that the statis- 
tical structure of the plaintext has been dissipated. Thus, the letter frequencies in the 
ciphertext will be more nearly equal than in the plaintext; the digram frequencies 
will also be more nearly equal, and so on. In a binary block cipher, diffusion can be 
achieved by repeatedly performing some permutation on the data followed by 
applying a function to that permutation; the effect is that bits from different 
positions in the original plaintext contribute to a single bit of ciphertext. 

Every block cipher involves a transformation of a block of plaintext into a 
block of ciphertext, where the transformation depends on the key. The mechanism 
of diffusion seeks to make the statistical relationship between the plaintext and 
ciphertext as complex as possible in order to thwart attempts to deduce the key. On 
the other hand, confusion seeks to make the relationship between the statistics of 
the ciphertext and the value of the encryption key as complex as possible, again to 
thwart attempts to discover the key. Thus, even if the attacker can get some handle 
on the statistics of the ciphertext, the way in which the key was used to produce that 
ciphertext is so complex as to make it difficult to deduce the key. This is achieved by 
the use of a complex substitution algorithm. In contrast, a simple linear substitution 
function would add little confusion. 

As [ROBS95b] points out, so successful are diffusion and confusion in captur- 
ing the essence of the desired attributes of a block cipher that they have become the 
cornerstone of modern block cipher design. 


FEISTEL CIPHER STRUCTURE The left-hand side of Figure 3.3 depicts the structure 
proposed by Feistel. The inputs to the encryption algorithm are a plaintext block of 
length 2w bits and a key K.The plaintext block is divided into two halves, Ly and Ro. 
The two halves of the data pass through n rounds of processing and then combine to 
produce the ciphertext block. Each round i has as inputs L;_, and R;_, derived from 
the previous round, as well as a subkey K; derived from the overall K. In general, 
the subkeys K; are different from K and from each other. In Figure 3.3, 16 rounds 
are used, although any number of rounds could be implemented. 

All rounds have the same structure. A substitution is performed on the left 
half of the data. This is done by applying a round function F to the right half of the 
data and then taking the exclusive-OR of the output of that function and the left 
half of the data. The round function has the same general structure for each round 
but is parameterized by the round subkey K;. Another way to express this is to say 
that F is a function of right-half block of w bits and a subkey of y bits, which pro- 
duces an output value of length w bits: F(RE;, K;.,). Following this substitution, a 


>Some books on cryptography equate permutation with diffusion. This is incorrect. Permutation, by itself, 
does not change the statistics of the plaintext at the level of individual letters or permuted blocks. For 
example, in DES, the permutation swaps two 32-bit blocks, so statistics of strings of 32 bits or less are 
preserved. 
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Figure 3.3 Feistel Encryption and Decryption (16 rounds) 


permutation is performed that consists of the interchange of the two halves of the 


data.° This structure is a particular form of the substitution-permutation network 
(SPN) proposed by Shannon. 


°The final round is followed by an interchange that undoes the interchange that is part of the final round. 
One could simply leave both interchanges out of the diagram, at the sacrifice of some consistency of 


presentation. In any case, the effective lack of a swap in the final round is done to simplify the implemen- 
tation of the decryption process, as we shall see. 


3.1 / BLOCK CIPHER PRINCIPLES 75 


The exact realization of a Feistel network depends on the choice of the following 
parameters and design features: 


e Block size: Larger block sizes mean greater security (all other things being 
equal) but reduced encryption/decryption speed for a given algorithm. The 
greater security is achieved by greater diffusion. Traditionally, a block size of 
64 bits has been considered a reasonable tradeoff and was nearly universal in 
block cipher design. However, the new AES uses a 128-bit block size. 


e Key size: Larger key size means greater security but may decrease encryption/ 
decryption speed. The greater security is achieved by greater resistance to 
brute-force attacks and greater confusion. Key sizes of 64 bits or less are now 
widely considered to be inadequate, and 128 bits has become a common size. 


e Number of rounds: The essence of the Feistel cipher is that a single round 
offers inadequate security but that multiple rounds offer increasing security. 
A typical size is 16 rounds. 


e Subkey generation algorithm: Greater complexity in this algorithm should 
lead to greater difficulty of cryptanalysis. 


e Round function F: Again, greater complexity generally means greater resistance 
to cryptanalysis. 


There are two other considerations in the design of a Feistel cipher: 


e Fast software encryption/decryption: In many cases, encryption is embedded 
in applications or utility functions in such a way as to preclude a hardware 
implementation. Accordingly, the speed of execution of the algorithm 
becomes a concern. 


e Ease of analysis: Although we would like to make our algorithm as difficult as 
possible to cryptanalyze, there is great benefit in making the algorithm easy to 
analyze. That is, if the algorithm can be concisely and clearly explained, it is 
easier to analyze that algorithm for cryptanalytic vulnerabilities and therefore 
develop a higher level of assurance as to its strength. DES, for example, does 
not have an easily analyzed functionality. 


FEISTEL DECRYPTION ALGORITHM The process of decryption with a Feistel cipher is 
essentially the same as the encryption process. The rule is as follows: Use the 
ciphertext as input to the algorithm, but use the subkeys K; in reverse order. That is, 
use K,, in the first round, K,,_; in the second round, and so on, until K, is used in the 
last round. This is a nice feature, because it means we need not implement two 
different algorithms; one for encryption and one for decryption. 

To see that the same algorithm with a reversed key order produces the correct 
result, Figure 3.3 shows the encryption process going down the left-hand side and 
the decryption process going up the right-hand side for a 16-round algorithm. For 
clarity, we use the notation LE; and RE; for data traveling through the encryption 
algorithm and LD; and RD; for data traveling through the decryption algorithm. 
The diagram indicates that, at every round, the intermediate value of the decryption 
process is equal to the corresponding value of the encryption process with the two 
halves of the value swapped. To put this another way, let the output of the ith 
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encryption round be LE||RE; (LE; concatenated with RE;). Then the corresponding 
output of the (16 — 7)th decryption round is RE;||LE; or, equivalently, LD1,6_ || RD 16_;- 

Let us walk through Figure 3.3 to demonstrate the validity of the preceding 
assertions. After the last iteration of the encryption process, the two halves of the 
output are swapped, so that the ciphertext is RE,,|LE,,.The output of that round is 
the ciphertext. Now take that ciphertext and use it as input to the same algorithm. 
The input to the first round is REj¢|LE,,, which is equal to the 32-bit swap of the 
output of the sixteenth round of the encryption process. 

Now we would like to show that the output of the first round of the decryption 
process is equal to a 32-bit swap of the input to the sixteenth round of the encryption 
process. First, consider the encryption process. We see that 


LE 46 = RE}; 
REi¢ = LE\s® F(RE}s, K16) 


On the decryption side, 


LD, = RDy = LE = RE\s5 
RD, = LD G F(RDp, Ki6) 
= RE\6® F(RE}s, Ki6) 
= [LE\5 ® F(RE}5, Ky)] ® F(RE\5, Kyo) 
The XOR has the following properties: 
[ASB])®@C=AE[BOEC 
D@®D=0 
E®O=E 
Thus, we have LD, = RE;; and RD, = LE;;. Therefore, the output of the first 
round of the decryption process is RE\5||LE 5, which is the 32-bit swap of the input 
to the sixteenth round of the encryption. This correspondence holds all the way 
through the 16 iterations, as is easily shown. We can cast this process in general 
terms. For the ith iteration of the encryption algorithm, 
LE; = RE,_; 
RE, = LE;_; ® F(RE,_1, Kj) 
Rearranging terms: 
RE;-, = LE; 
LE; = RE; ®@ F(RE,-1, K)) = RE; ®@ F(LE,, K;) 


Thus, we have described the inputs to the ith iteration as a function of the outputs, and 
these equations confirm the assignments shown in the right-hand side of Figure 3.3. 

Finally, we see that the output of the last round of the decryption process is 
RE )||LE . A 32-bit swap recovers the original plaintext, demonstrating the validity 
of the Feistel decryption process. 

Note that the derivation does not require that F be a reversible function. To 
see this, take a limiting case in which F produces a constant output (e.g., all ones) 
regardless of the values of its two arguments. The equations still hold. 
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Figure 3.4 Feistel Example 


To help clarify the preceding concepts, let us look at a specific example (Figure 3.4) 
and focus on the fifteenth round of encryption, corresponding to the second round of 
decryption. Suppose that the blocks at each stage are 32 bits (two 16-bit halves) and that 
the key size is 24 bits. Suppose that at the end of encryption round fourteen, the value of 
the intermediate block (in hexadecimal) is DE7F0O3A6. Then LE,, = DE7F and 
RE\4 = 03A6. Also assume that the value of K,5 is 12DES2. After round 15, we have 
LE,5 =03A6 and RE;; = F(03A6, 12DES52) ® DE7F. 

Now let’s look at the decryption. We assume that LD; = RE,5 and RD, = LE}s, 
as shown in Figure 3.3, and we want to demonstrate that LD, = RE,4 and 
RD», = LE\4.So, we start with LD, = F(03A6, 12DE52) ® DE7F and RD, = 03A6. 
Then, from Figure 3.3, LD, = 03A6 = RE,4 and RD» = F(03A6, 12DE52) ® 
[F(03A6, 12DE52) ® DE7F]= DE7F = LE 4. 


3.2 THE DATA ENCRYPTION STANDARD 


The most widely used encryption scheme is based on the Data Encryption Standard 
(DES) adopted in 1977 by the National Bureau of Standards, now the National 
Institute of Standards and Technology (NIST), as Federal Information Processing 
Standard 46 (FIPS PUB 46). The algorithm itself is referred to as the Data 
Encryption Algorithm (DEA).’ For DES, data are encrypted in 64-bit blocks using 
a 56-bit key. The algorithm transforms 64-bit input in a series of steps into a 64-bit 
output. The same steps, with the same key, are used to reverse the encryption. 

The DES enjoys widespread use. It has also been the subject of much controversy 
concerning how secure the DES is. To appreciate the nature of the controversy, let us 
quickly review the history of the DES. 


’The terminology is a bit confusing. Until recently, the terms DES and DEA could be used interchange- 
ably. However, the most recent edition of the DES document includes a specification of the DEA 
described here plus the triple DEA (TDEA) described in Chapter 6. Both DEA and TDEA are part of 
the Data Encryption Standard. Further, until the recent adoption of the official term TDEA, the triple 
DEA algorithm was typically referred to as triple DES and written as 3DES. For the sake of convenience, 
we will use the term 3DES. 
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In the late 1960s, IBM set up a research project in computer cryptography led by 
Horst Feistel. The project concluded in 1971 with the development of an algorithm 
with the designation LUCIFER [FEIS73], which was sold to Lloyd’s of London for 
use in a cash-dispensing system, also developed by IBM. LUCIFER is a Feistel block 
cipher that operates on blocks of 64 bits, using a key size of 128 bits. Because of the 
promising results produced by the LUCIFER project, IBM embarked on an effort to 
develop a marketable commercial encryption product that ideally could be imple- 
mented on a single chip. The effort was headed by Walter Tuchman and Carl Meyer, 
and it involved not only IBM researchers but also outside consultants and technical 
advice from the National Security Agency (NSA). The outcome of this effort was a 
refined version of LUCIFER that was more resistant to cryptanalysis but that had a 
reduced key size of 56 bits, in order to fit on a single chip. 

In 1973, the National Bureau of Standards (NBS) issued a request for proposals 
for a national cipher standard. IBM submitted the results of its Tuchman—Meyer 
project. This was by far the best algorithm proposed and was adopted in 1977 as the 
Data Encryption Standard. 

Before its adoption as a standard, the proposed DES was subjected to intense 
criticism, which has not subsided to this day. Two areas drew the critics’ fire. First, 
the key length in IBM’s original LUCIFER algorithm was 128 bits, but that of the 
proposed system was only 56 bits, an enormous reduction in key size of 72 bits. 
Critics feared that this key length was too short to withstand brute-force attacks. 
The second area of concern was that the design criteria for the internal structure of 
DES, the S-boxes, were classified. Thus, users could not be sure that the internal 
structure of DES was free of any hidden weak points that would enable NSA to 
decipher messages without benefit of the key. Subsequent events, particularly the 
recent work on differential cryptanalysis, seem to indicate that DES has a very 
strong internal structure. Furthermore, according to IBM participants, the only 
changes that were made to the proposal were changes to the S-boxes, suggested by 
NSA, that removed vulnerabilities identified in the course of the evaluation process. 

Whatever the merits of the case, DES has flourished and is widely used, especially 
in financial applications. In 1994, NIST reaffirmed DES for federal use for another five 
years; NIST recommended the use of DES for applications other than the protection of 
classified information. In 1999, NIST issued a new version of its standard (FIPS PUB 
46-3) that indicated that DES should be used only for legacy systems and that triple 
DES (which in essence involves repeating the DES algorithm three times on the plain- 
text using two or three different keys to produce the ciphertext) be used. We study triple 
DES in Chapter 6. Because the underlying encryption and decryption algorithms are 
the same for DES and triple DES, it remains important to understand the DES cipher. 


DES Encryption 


The overall scheme for DES encryption is illustrated in Figure 3.5. As with any 
encryption scheme, there are two inputs to the encryption function: the plaintext to 
be encrypted and the key. In this case, the plaintext must be 64 bits in length and the 
key is 56 bits in length.® 


S Actually, the function expects a 64-bit key as input. However, only 56 of these bits are ever used; the 
other 8 bits can be used as parity bits or simply set arbitrarily. 
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64-bit plaintext 64-bit key 
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Permuted choice | 
56 
Permuted choice 2 Left circular shift 
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Initial permutation 


64 


Round | 


Y 
Round 16 


32-bit swap 


64 bits 


Inverse initial 
permutation 
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64-bit ciphertext 


Permuted choice 2 Left circular shift 


Figure 3.5 General Depiction of DES Encryption Algorithm 


Looking at the left-hand side of the figure, we can see that the processing of 
the plaintext proceeds in three phases. First, the 64-bit plaintext passes through an 
initial permutation (IP) that rearranges the bits to produce the permuted input. 
This is followed by a phase consisting of sixteen rounds of the same function, 
which involves both permutation and substitution functions. The output of the last 
(sixteenth) round consists of 64 bits that are a function of the input plaintext and 
the key. The left and right halves of the output are swapped to produce the 
preoutput. Finally, the preoutput is passed through a permutation [IP ‘] that is the 
inverse of the initial permutation function, to produce the 64-bit ciphertext. With 
the exception of the initial and final permutations, DES has the exact structure of 
a Feistel cipher, as shown in Figure 3.3. 

The right-hand portion of Figure 3.5 shows the way in which the 56-bit key 
is used. Initially, the key is passed through a permutation function. Then, for each 
of the sixteen rounds, a subkey (K;) is produced by the combination of a left 
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circular shift and a permutation. The permutation function is the same for each 
round, but a different subkey is produced because of the repeated shifts of the 
key bits. 


INITIAL PERMUTATION The initial permutation and its inverse are defined by tables, 
as shown in Tables 3.2a and 3.2b, respectively. The tables are to be interpreted as 
follows. The input to a table consists of 64 bits numbered from 1 to 64. The 64 entries 
in the permutation table contain a permutation of the numbers from 1 to 64. Each 


Table 3.2 Permutation Tables for DES 
(a) Initial Permutation (IP) 


JINN WrP OD FN 


8 
W 
6 
3) 
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3 
2 
1 
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entry in the permutation table indicates the position of a numbered input bit in the 
output, which also consists of 64 bits. 

To see that these two permutation functions are indeed the inverse of each 
other, consider the following 64-bit input M: 


M, M, Mz; Ms Ms Me M, Mg 


where M,; is a binary digit. Then the permutation ¥ = (IP(M) is as follows: 


Msg Ms My M34 My Mig Mio M, 

4 M6 Mog Mx M1 Ms 
Me2 Ms4 M46 M3 Mx Mx M14 Me 

8 My M32 My, M6 Ms 
Ms; May Ma M33 Mp5 Mi, My M, 
Ms» Ms, Ma M35 My, M9 My, M; 
Me Ms3 Ms M37 Mo My M43 Ms 
Me3 Mss Ma M39 M3, My Mis M, 


If we then take the inverse permutation Y = IP-'(X) = IP '(IP(M)),it can be 
seen that the original ordering of the bits is restored. 


DETAILS OF SINGLE RouND Figure 3.6 shows the internal structure of a single round. 
Again, begin by focusing on the left-hand side of the diagram. The left and right 
halves of each 64-bit intermediate value are treated as_ separate 
32-bit quantities, labeled L (left) and R (right). As in any classic Feistel cipher, the 
overall processing at each round can be summarized in the following formulas: 


Lb; = Rey 
Re = Ly PURE i Ki) 


The round key K; is 48 bits. The R input is 32 bits. This R input is first 
expanded to 48 bits by using a table that defines a permutation plus an expansion 
that involves duplication of 16 of the R bits (Table 3.2c). The resulting 48 bits are 
XORed with K;. This 48-bit result passes through a substitution function that 
produces a 32-bit output, which is permuted as defined by Table 3.2d. 

The role of the S-boxes in the function F is illustrated in Figure 3.7. The substi- 
tution consists of a set of eight S-boxes, each of which accepts 6 bits as input and 
produces 4 bits as output. These transformations are defined in Table 3.3, which is 
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~<— 32bits —» =<— 32bits —» ~<— 28 bits —> ~<— 28 bits —> 


v 1 


Expansion/permutation Left shift(s) 
(E table) 


148 
Permutation/contraction 

F Ag Kj (Permuted choice 2) 

A448 

Y 
Substitution/choice 

(S-box) 
A 32 


Permutation 


() 


A 32 


Figure 3.6 Single Round of DES Algorithm 


interpreted as follows: The first and last bits of the input to box S; form a 2-bit binary 
number to select one of four substitutions defined by the four rows in the table for S;. 
The middle four bits select one of the sixteen columns. The decimal value in the cell 
selected by the row and column is then converted to its 4-bit representation to pro- 
duce the output. For example, in Sj, for input 011001, the row is 01 (row 1) and the 
column is 1100 (column 12). The value in row 1, column 12 is 9, so the output is 1001. 

Each row of an S-box defines a general reversible substitution. Figure 3.2 may 
be useful in understanding the mapping. The figure shows the substitution for row 0 
of box S;. 

The operation of the S-boxes is worth further comment. Ignore for the moment 
the contribution of the key (K;). If you examine the expansion table, you see that the 
32 bits of input are split into groups of 4 bits and then become groups of 6 bits by taking 
the outer bits from the two adjacent groups. For example, if part of the input word is 


efgh ijkl mnop 
this becomes 


defghi hijklm lmnopq 
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R (2 bits) 


48 bits K (48 bits) 


32 bits 


Figure 3.7 Calculation of F(R, K) 


The outer two bits of each group select one of four possible substitutions (one row 
of an S-box). Then a 4-bit output value is substituted for the particular 4-bit input 
(the middle four input bits). The 32-bit output from the eight S-boxes is then 
permuted, so that on the next round, the output from each S-box immediately 
affects as many others as possible. 


Key GENERATION Returning to Figures 3.5 and 3.6, we see that a 64-bit key is used 
as input to the algorithm. The bits of the key are numbered from 1 through 64; every 
eighth bit is ignored, as indicated by the lack of shading in Table 3.4a. The key is first 
subjected to a permutation governed by a table labeled Permuted Choice One 
(Table 3.4b). The resulting 56-bit key is then treated as two 28-bit quantities, labeled 
Cp and Do. At each round, C;_; and D;_; are separately subjected to a circular left 
shift or (rotation) of 1 or 2 bits, as governed by Table 3.4d. These shifted values serve 
as input to the next round. They also serve as input to the part labeled Permuted 
Choice Two (Table 3.4c), which produces a 48-bit output that serves as input to the 
function F(R;-1, K;). 


DES Decryption 


As with any Feistel cipher, decryption uses the same algorithm as encryption, except 
that the application of the subkeys is reversed. 


Definition of DES S-Boxes 
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Table 3.4 DES Key Schedule Calculation 
(a) Input Key 


Rewmadlinimmcse it 2 3 4 5S @ F 8 @ iO dh dm ie te We ie 
Bits Rotated Se PE PS tk 2 2 2 2 2 2 il 


3.3 A DES EXAMPLE 


We now work through an example and consider some of its implications. Although 
you are not expected to duplicate the example by hand, you will find it informative 
to study the hex patterns that occur from one step to the next. 

For this example, the plaintext is a hexadecimal palindrome. The plaintext, key, 
and resulting ciphertext are as follows: 


Plaintext: 02468aceeca86420 
Key: 0£1571c947d9e859 
Ciphertext: | da02ce3a89ecac3b 
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Results 


Table 3.5 shows the progression of the algorithm. The first row shows the 32-bit 
values of the left and right halves of data after the initial permutation. The next 
16 rows show the results after each round. Also shown is the value of the 48-bit 
subkey generated for each round. Note that L; = R;_,.The final row shows the left- 
and right-hand values after the inverse initial permutation. These two values com- 
bined form the ciphertext. 


The Avalanche Effect 


A desirable property of any encryption algorithm is that a small change in either the 
plaintext or the key should produce a significant change in the ciphertext. In partic- 
ular, a change in one bit of the plaintext or one bit of the key should produce a 
change in many bits of the ciphertext. This is referred to as the avalanche effect. If 
the change were small, this might provide a way to reduce the size of the plaintext or 
key space to be searched. 

Using the example from Table 3.5, Table 3.6 shows the result when the fourth 
bit of the plaintext is changed, so that the plaintext is 12468aceeca86420. The 
second column of the table shows the intermediate 64-bit values at the end of each 
round for the two plaintexts. The third column shows the number of bits that differ 
between the two intermediate values. The table shows that, after just three rounds, 
18 bits differ between the two blocks. On completion, the two ciphertexts differ in 
32 bit positions. 


Table 3.5 DES Example 


5a005a00 REO Sele 
1e030£03080d2930 3cf£03c0f bad22845 
0a31293432242318 bad22845 99e9b723 
23072318201d0c1d 992695723 Obae3b9e 
05261d3824311a20 Obae3b9e 42415649 
33253401360026e25 42415649 18b3fa41 
123a2d0d04262alc 18b3 fa41 9616fe23 
021£120b1c130611 9616fe23 G7 Mal oie2 
1¢10372a2832002b Gee? cllbfc09 
04292a380c341£03 cllbfc09 887fbcb6c 
2703212607280403 887f£bcb6c 600f7e8b 
2826390c31261504 600£7e8b £596506e 
12071c241a0a0£08 £596506e 738538b8 
300935393c0d100b 738538b8 c6ab2c4e 
311e09231321182a c6ab2c4e 56b0bd75 
283d3e0227072528 56b0bd75 75e8fd8ft 
2921080b13143025 75e8£d8£t 25896490 
da02ce3a 89ecac3b 
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Note: DES subkeys are shown as eight 6-bit values in hex format 


Avalanche Effect in DES: Change in Plaintext 


02468aceeca86420 
12468aceeca86420 
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3cf£03c0fbad22845 
3cf£03c0fbad32845 


cllbfc09887fbc6c 
ORs Zeed/ Aga 


bad2284599e9b723 
bad3284539a9b7a3 


887fbcec600f7e8b 
2eced7d94d0£23094 


99e9b7230bae3b9e 
39a9b7a3171cb8b3 
Obae3b9e42415649 
17licbh8b3ccaca55e 


600f£7e8b£596506e 
d0£23094455da9c4 


£596506e738538b8 
455da9c47fbe3ct3 


ADATS6ASLSbS tat lt 
ecaca55ed16¢c3653 


738538b8cb6ab2c4e 
7T£6e3cf34bclas8d9 


18b3£a419616fe23 
d16c3653cf402c68 


c6ab2c4e56b0bd75 
4bc1a8d91e07d409 


8616fe23 6711 7er2 
cf402c682bacefbc 


56b0bd7575e8f£d8£ 
1e07d4091ce2e6dc 
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75e8£d8£25896490 
lce2e6dc365e5£59 


da02ce3a89ecac3b 
057cde97d7683£2a 


Table 3.7 shows a similar test using the original plaintext of with two keys that 
differ in only the fourth bit position: the original key, 0£1571¢c947d9e859, and the 
altered key, 1£1571¢c947d9e859. Again, the results show that about half of the bits in 
the ciphertext differ and that the avalanche effect is pronounced after just a few rounds. 


Table 3.7 Avalanche Effect in DES: Change in Key 


02468aceeca86420 
02468aceeca86420 


3c£03c0fbad22845 
3c£03c0f9ad628c5 


cllb£c09887£bc6c 
548f1de471f£64dfd 


bad2284599e9b723 
9ad628c59939136b 


887£bco6c600F7e8b 
71£64d£d4279876c 


99e9b7230bae3b9e 
9939136b768067b7 


600f7e8b£596506e 
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3.4 THE STRENGTH OF DES 


Since its adoption as a federal standard, there have been lingering concerns about 
the level of security provided by DES. These concerns, by and large, fall into two 
areas: key size and the nature of the algorithm. 


The Use of 56-Bit Keys 


With a key length of 56 bits, there are 2°° possible keys, which is approximately 
7.2 x 10'° keys. Thus, on the face of it, a brute-force attack appears impractical. 
Assuming that, on average, half the key space has to be searched, a single machine 
performing one DES encryption per microsecond would take more than a thousand 
years (see Table 2.2) to break the cipher. 

However, the assumption of one encryption per microsecond is overly conser- 
vative. As far back as 1977, Diffie and Hellman postulated that the technology 
existed to build a parallel machine with 1 million encryption devices, each of which 
could perform one encryption per microsecond [DIFF77]. This would bring the 
average search time down to about 10 hours. The authors estimated that the cost 
would be about $20 million in 1977 dollars. 

DES finally and definitively proved insecure in July 1998, when the Electronic 
Frontier Foundation (EFF) announced that it had broken a DES encryption using a 
special-purpose “DES cracker” machine that was built for less than $250,000. 
The attack took less than three days. The EFF has published a detailed description of 
the machine, enabling others to build their own cracker [EFF98]. And, of course, hard- 
ware prices will continue to drop as speeds increase, making DES virtually worthless. 

It is important to note that there is more to a key-search attack than simply 
running through all possible keys. Unless known plaintext is provided, the analyst 
must be able to recognize plaintext as plaintext. If the message is just plain text in 
English, then the result pops out easily, although the task of recognizing English 
would have to be automated. If the text message has been compressed before 
encryption, then recognition is more difficult. And if the message is some more gen- 
eral type of data, such as a numerical file, and this has been compressed, the prob- 
lem becomes even more difficult to automate. Thus, to supplement the brute-force 
approach, some degree of knowledge about the expected plaintext is needed, and 
some means of automatically distinguishing plaintext from garble is also needed. 
The EFF approach addresses this issue as well and introduces some automated 
techniques that would be effective in many contexts. 

Fortunately, there are a number of alternatives to DES, the most important of 
which are AES and triple DES, discussed in Chapters 5 and 6, respectively. 


The Nature of the DES Algorithm 


Another concern is the possibility that cryptanalysis is possible by exploiting the 
characteristics of the DES algorithm. The focus of concern has been on the eight 
substitution tables, or S-boxes, that are used in each iteration. Because the design 
criteria for these boxes, and indeed for the entire algorithm, were not made public, 
there is a suspicion that the boxes were constructed in such a way that cryptanalysis 
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is possible for an opponent who knows the weaknesses in the S-boxes. This assertion 
is tantalizing, and over the years a number of regularities and unexpected behaviors 
of the S-boxes have been discovered. Despite this, no one has so far succeeded in 
discovering the supposed fatal weaknesses in the S-boxes.” 


Timing Attacks 


We discuss timing attacks in more detail in Part Two, as they relate to public-key 
algorithms. However, the issue may also be relevant for symmetric ciphers. 
In essence, a timing attack is one in which information about the key or the plaintext 
is obtained by observing how long it takes a given implementation to perform 
decryptions on various ciphertexts. A timing attack exploits the fact that an encryp- 
tion or decryption algorithm often takes slightly different amounts of time on 
different inputs. [HEVI99] reports on an approach that yields the Hamming weight 
(number of bits equal to one) of the secret key. This is a long way from knowing the 
actual key, but it is an intriguing first step. The authors conclude that DES appears 
to be fairly resistant to a successful timing attack but suggest some avenues to 
explore. Although this is an interesting line of attack, it so far appears unlikely that 
this technique will ever be successful against DES or more powerful symmetric 
ciphers such as triple DES and AES. 


3.5 DIFFERENTIAL AND LINEAR CRYPTANALYSIS 


For most of its life, the prime concern with DES has been its vulnerability 
to brute-force attack because of its relatively short (56 bits) key length. However, 
there has also been interest in finding cryptanalytic attacks on DES. With 
the increasing popularity of block ciphers with longer key lengths, including 
triple DES, brute-force attacks have become increasingly impractical. Thus, 
there has been increased emphasis on cryptanalytic attacks on DES and other 
symmetric block ciphers. In this section, we provide a brief overview of the two 
most powerful and promising approaches: differential cryptanalysis and linear 
cryptanalysis. 


Differential Cryptanalysis 


One of the most significant advances in cryptanalysis in recent years is differential 
cryptanalysis. In this section, we discuss the technique and its applicability to DES. 


History Differential cryptanalysis was not reported in the open literature until 
1990. The first published effort appears to have been the cryptanalysis of a block 
cipher called FEAL by Murphy [MURP90]. This was followed by a number of 
papers by Biham and Shamir, who demonstrated this form of attack on a variety of 
encryption algorithms and hash functions; their results are summarized in 
[BIHA93]. 


°At least, no one has publicly acknowledged such a discovery. 
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The most publicized results for this approach have been those that have 
application to DES. Differential cryptanalysis is the first published attack that is 
capable of breaking DES in less than 2°° encryptions. The scheme, as reported in 
[BIHA93], can successfully cryptanalyze DES with an effort on the order of 2*” 
encryptions, requiring 2*’ chosen plaintexts. Although 2” is certainly significantly 
less than 2°°, the need for the adversary to find 2” chosen plaintexts makes this 
attack of only theoretical interest. 

Although differential cryptanalysis is a powerful tool, it does not do very well 
against DES. The reason, according to a member of the IBM team that designed 
DES [COPP94], is that differential cryptanalysis was known to the team as early as 
1974. The need to strengthen DES against attacks using differential cryptanalysis 
played a large part in the design of the S-boxes and the permutation P. As evidence 
of the impact of these changes, consider these comparable results reported in 
[BIHA93]. Differential cryptanalysis of an eight-round LUCIFER algorithm 
requires only 256 chosen plaintexts, whereas an attack on an eight-round version of 
DES requires 2'* chosen plaintexts. 


DIFFERENTIAL CRYPTANALYSIS ATTACK The differential cryptanalysis attack is complex; 
[BIHA93] provides a complete description. The rationale behind differential 
cryptanalysis is to observe the behavior of pairs of text blocks evolving along each 
round of the cipher, instead of observing the evolution of a single text block. Here, we 
provide a brief overview so that you can get the flavor of the attack. 

We begin with a change in notation for DES. Consider the original plaintext 
block m to consist of two halves mo, m,;. Each round of DES maps the right-hand 
input into the left-hand output and sets the right-hand output to be a function of the 
left-hand input and the subkey for this round. So, at each round, only one new 32-bit 
block is created. If we label each new block m;(2 = i = 17), then the intermediate 
message halves are related as follows: 


Mj44 = m1 © {(m,, Kj), i= 1,2, aes 16 


In differential cryptanalysis, we start with two messages, m and m’, with a 
known XOR difference Am = m © m'’, and consider the difference between the 
intermediate message halves: Am; = m;®m';. Then we have 

Amiy1 = Mi+1 OM’ j41 
= [m,-1 ® f(m,, K;j)] ® [m'-1 ® f(m';, Kj) ] 
Am;-; ® [f(m;, Ki) ® f(m, Ki)] 


Now, suppose that many pairs of inputs to f with the same difference yield the 
same output difference if the same subkey is used. To put this more precisely, let us 
say that X may cause Y with probability p,if for a fraction p of the pairs in which the 
input XOR is_X, the output XOR equals Y. We want to suppose that there are a 
number of values of X that have high probability of causing a particular output 
difference. Therefore, if we know Am;_, and Am; with high probability, then we 
know Am;,, with high probability. Furthermore, if a number of such differences are 
determined, it is feasible to determine the subkey used in the function f. 

The overall strategy of differential cryptanalysis is based on these considerations 
for a single round. The procedure is to begin with two plaintext messages m and m' 
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with a given difference and trace through a probable pattern of differences after each 
round to yield a probable difference for the ciphertext. Actually, there are two proba- 
ble patterns of differences for the two 32-bit halves: (Am,7|| A77j,). Next, we submit m 
and m’' for encryption to determine the actual difference under the unknown key and 
compare the result to the probable difference. If there is a match, 


E(K, m) ® E(K,m') = (Amy7|| Amy) 


then we suspect that all the probable patterns at all the intermediate rounds are 
correct. With that assumption, we can make some deductions about the key bits. 
This procedure must be repeated many times to determine all the key bits. 

Figure 3.8, based on a figure in [BIHA93], illustrates the propagation of differ- 
ences through three rounds of DES. The probabilities shown on the right refer to 
the probability that a given set of intermediate differences will appear as a function 


Am,_, || Am; = 40 08 00 00 04 00 00 00 


£(Am,) = 40 08 00 00 Am; = 04 00 00 00 


p = 0.25 


i+1) = 00 00 00 00 Am;.; = 00.00 00 00 


i+2) = 40 08 00 00 Am; = 04 00 00 00 


p = 0.25 


Am431l Amzs2 = 40 08 00 00 04 00 00 00 


Figure 3.8 Differential Propagation through Three Rounds of DES 
(numbers in hexadecimal) 
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of the input differences. Overall, after three rounds, the probability that the output 
difference is as shown is equal to 0.25 X 1 X 0.25 = 0.0625. 


Linear Cryptanalysis 


A more recent development is linear cryptanalysis, described in [MATS93]. This attack 
is based on finding linear approximations to describe the transformations performed in 
DES. This method can find a DES key given 2° known plaintexts, as compared to 24” 
chosen plaintexts for differential cryptanalysis. Although this is a minor improvement, 
because it may be easier to acquire known plaintext rather than chosen plaintext, it still 
leaves linear cryptanalysis infeasible as an attack on DES. So far, little work has been 
done by other groups to validate the linear cryptanalytic approach. 

We now give a brief summary of the principle on which linear cryptanalysis is 
based. For a cipher with n-bit plaintext and ciphertext blocks and an m-bit key, let 
the plaintext block be labeled P[1], ...P[m], the cipher text block C[1], ...C[n], 
and the key K[1], ..., K[m].Then define 


Ali j,.... kK] = AL] @ AL] @ ... @ A[K] 


The objective of linear cryptanalysis is to find an effective /inear equation of 
the form: 


Play, a, gta ®C[Bi, Bo, Panisiig Bo] = K[v1, Y2> cng Vel 


(where x = 0 or1;1 S$ a;b = n;c S m;and where the a, B, and y terms represent 
fixed, unique bit locations) that holds with probability p # 0.5. The further p is from 
0.5, the more effective the equation. Once a proposed relation is determined, the pro- 
cedure is to compute the results of the left-hand side of the preceding equation for a 
large number of plaintext-ciphertext pairs. If the result is 0 more than half the time, 
assume K[y;, y2, ---, Yc] = 0. Ifit is 1 most of the time, assume K[y, y2, ..., y-] = 1. 
This gives us a linear equation on the key bits. Try to get more such relations so that we 
can solve for the key bits. Because we are dealing with linear equations, the problem 
can be approached one round of the cipher at a time, with the results combined. 


3.6 BLOCK CIPHER DESIGN PRINCIPLES 


Although much progress has been made in designing block ciphers that are crypto- 
graphically strong, the basic principles have not changed all that much since the 
work of Feistel and the DES design team in the early 1970s. It is useful to begin this 
discussion by looking at the published design criteria used in the DES effort. Then 
we look at three critical aspects of block cipher design: the number of rounds, design 
of the function F, and key scheduling. 


DES Design Criteria 


The criteria used in the design of DES, as reported in [COPP94], focused on the 
design of the S-boxes and on the P function that takes the output of the S-boxes 
(Figure 3.7). The criteria for the S-boxes are as follows. 


nN 


mn 


6. 
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. No output bit of any S-box should be too close a linear function of the 


input bits. Specifically, if we select any output bit and any subset of the 
six input bits, the fraction of inputs for which this output bit equals 
the XOR of these input bits should not be close to 0 or 1, but rather should 
be near 1/2. 


. Each row of an S-box (determined by a fixed value of the leftmost and right- 


most input bits) should include all 16 possible output bit combinations. 


. If two inputs to an S-box differ in exactly one bit, the outputs must differ in at 


least two bits. 


. If two inputs to an S-box differ in the two middle bits exactly, the outputs must 


differ in at least two bits. 


. If two inputs to an S-box differ in their first two bits and are identical in their last 


two bits, the two outputs must not be the same. 


For any nonzero 6-bit difference between inputs, no more than eight of the 
32 pairs of inputs exhibiting that difference may result in the same output 
difference. 


. This is a criterion similar to the previous one, but for the case of three 


S-boxes. 


Coppersmith pointed out that the first criterion in the preceding list was 


needed because the S-boxes are the only nonlinear part of DES. If the S-boxes 
were linear (i.e., each output bit is a linear combination of the input bits), the 
entire algorithm would be linear and easily broken. We have seen this phenome- 
non with the Hill cipher, which is linear. The remaining criteria were primarily 
aimed at thwarting differential cryptanalysis and at providing good confusion 
properties. 


nN 


3. 


The criteria for the permutation P are as follows. 


. The four output bits from each S-box at round i are distributed so that two of 


them affect (provide input for) “middle bits” of round (i + 1) and the other 
two affect end bits. The two middle bits of input to an S-box are not shared 
with adjacent S-boxes. The end bits are the two left-hand bits and the two 
right-hand bits, which are shared with adjacent S-boxes. 


. The four output bits from each S-box affect six different S-boxes on the next 


round, and no two affect the same S-box. 


For two S-boxes j, k, if an output bit from S; affects a middle bit of S; on the 
next round, then an output bit from S; cannot affect a middle bit of S;. This 
implies that, for j = k, an output bit from S; must not affect a middle bit of S;. 


These criteria are intended to increase the diffusion of the algorithm. 


Number of Rounds 


The cryptographic strength of a Feistel cipher derives from three aspects of the 
design: the number of rounds, the function F, and the key schedule algorithm. Let us 
look first at the choice of the number of rounds. 
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The greater the number of rounds, the more difficult it is to perform crypt- 
analysis, even for a relatively weak F. In general, the criterion should be that the 
number of rounds is chosen so that known cryptanalytic efforts require greater 
effort than a simple brute-force key search attack. This criterion was certainly used 
in the design of DES. Schneier [SCHN96] observes that for 16-round DES, a differ- 
ential cryptanalysis attack is slightly less efficient than brute force: The differential 
cryptanalysis attack requires 2>! operations,!° whereas brute force requires 2>°. If 
DES had 15 or fewer rounds, differential cryptanalysis would require less effort 
than a brute-force key search. 

This criterion is attractive, because it makes it easy to judge the strength of an 
algorithm and to compare different algorithms. In the absence of a cryptanalytic 
breakthrough, the strength of any algorithm that satisfies the criterion can be 
judged solely on key length. 


Design of Function F 


The heart of a Feistel block cipher is the function F. As we have seen, in DES, this 
function relies on the use of S-boxes. This is also the case for many other symmetric 
block ciphers. However, we can make some general comments about the criteria for 
designing F. After that, we look specifically at S-box design. 


DESIGN CRITERIA FOR F The function F provides the element of confusion in a 
Feistel cipher. Thus, it must be difficult to “unscramble” the substitution performed 
by F. One obvious criterion is that F be nonlinear, as we discussed previously. The 
more nonlinear F, the more difficult any type of cryptanalysis will be. There are 
several measures of nonlinearity, which are beyond the scope of this book. In rough 
terms, the more difficult it is to approximate F by a set of linear equations, the more 
nonlinear F is. 

Several other criteria should be considered in designing F. We would like 
the algorithm to have good avalanche properties. Recall that, in general, 
this means that a change in one bit of the input should produce a change in many 
bits of the output. A more stringent version of this is the strict avalanche 
criterion (SAC) [WEBS86], which states that any output bit j of an S-box should 
change with probability 1/2 when any single input bit 7 is inverted for all i, j. 
Although SAC is expressed in terms of S-boxes, a similar criterion could be 
applied to F as a whole. This is important when considering designs that do not 
include S-boxes. 

Another criterion proposed in [WEBS86] is the bit independence criterion 
(BIC), which states that output bits j and k should change independently when any 
single input bit 7 is inverted for all i, j, and k. The SAC and BIC criteria appear to 
strengthen the effectiveness of the confusion function. 


S-Box Desicn One of the most intense areas of research in the field of symmetric 
block ciphers is that of S-box design. The papers are almost too numerous to 


!0Recall that differential cryptanalysis of DES requires 2”’ chosen plaintext. If all you have to work with 
is known plaintext, then you must sort through a large quantity of known plaintext—ciphertext pairs look- 
ing for the useful ones. This brings the level of effort up to 2°>". 
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count.!! Here we mention some general principles. In essence, we would like any 
change to the input vector to an S-box to result in random-looking changes to the 
output. The relationship should be nonlinear and difficult to approximate with 
linear functions. 

One obvious characteristic of the S-box is its size. Ann X m S-box has n input 
bits and m output bits. DES has 6 X< 4 S-boxes. The encryption algorithm Blowfish, 
has 8 X 32 S-boxes. Larger S-boxes, by and large, are more resistant to differential 
and linear cryptanalysis [SCHN96]. On the other hand, the larger the dimension n, 
the (exponentially) larger the lookup table. Thus, for practical reasons, a limit of n 
equal to about 8 to 10 is usually imposed. Another practical consideration is that the 
larger the S-box, the more difficult it is to design it properly. 

S-boxes are typically organized in a different manner than used in DES. An 
n X m S-box typically consists of 2” rows of m bits each. The 1 bits of input select 
one of the rows of the S-box, and the m bits in that row are the output. For example, 
in an 8 X 32 S-box, if the input is 00001001, the output consists of the 32 bits in 
row 9 (the first row is labeled row 0). 

Mister and Adams [MIST96] propose a number of criteria for S-box design. 
Among these are that the S-box should satisfy both SAC and BIC. They also suggest 
that all linear combinations of S-box columns should be bent. Bent functions are a 
special class of Boolean functions that are highly nonlinear according to certain 
mathematical criteria [ADAM90]. There has been increasing interest in designing 
and analyzing S-boxes using bent functions. 

A related criterion for S-boxes is proposed and analyzed in [HE YS95]. The 
authors define the guaranteed avalanche (GA) criterion as follows: An S-box satisfies 
GA of order y if, for a 1-bit input change, at least y output bits change. The authors 
conclude that a GA in the range of order 2 to order 5 provides strong diffusion 
characteristics for the overall encryption algorithm. 

For larger S-boxes, such as 8 X 32, the question arises as to the best method 
of selecting the S-box entries in order to meet the type of criteria we have been 
discussing. Nyberg, who has written a lot about the theory and practice of S-box 
design, suggests the following approaches (quoted in [ROBS95b]): 


e Random: Use some pseudorandom number generation or some table of random 
digits to generate the entries in the S-boxes. This may lead to boxes with undesir- 
able characteristics for small sizes (e.g.,6 4) but should be acceptable for large 
S-boxes (e.g.,8 X 32). 

e Random with testing: Choose S-box entries randomly, then test the results 
against various criteria, and throw away those that do not pass. 

e Human-made: This is a more or less manual approach with only simple mathe- 
matics to support it. It is apparently the technique used in the DES design. This 
approach is difficult to carry through for large S-boxes. 

e Math-made: Generate S-boxes according to mathematical principles. By using 
mathematical construction, S-boxes can be constructed that offer proven security 
against linear and differential cryptanalysis, together with good diffusion. 


11A good summary of S-box design studies through early 1996 can be found in [SCHN96]. 
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A variation on the first technique is to use S-boxes that are both random and key 
dependent. An example of this approach is Blowfish, which starts with S-boxes filled 
with pseudorandom digits and then alters the contents using the key. A tremendous 
advantage of key-dependent S-boxes is that, because they are not fixed, it is impossible 
to analyze the S-boxes ahead of time to look for weaknesses. 


Key Schedule Algorithm 


A final area of block cipher design, and one that has received less attention than 
S-box design, is the key schedule algorithm. With any Feistel block cipher, the key is 
used to generate one subkey for each round. In general, we would like to select 
subkeys to maximize the difficulty of deducing individual subkeys and the difficulty 
of working back to the main key. No general principles for this have yet been 
promulgated. 

Hall suggests [ADAM94] that, at minimum, the key schedule should guarantee 
key/ciphertext Strict Avalanche Criterion and Bit Independence Criterion. 


3.7 RECOMMENDED READING AND WEB SITE 


There is a wealth of information on symmetric encryption. Some of the more worthwhile 
references are listed here. An essential reference work is [SCHN96]. This remarkable work 
contains descriptions of virtually every cryptographic algorithm and protocol published up 
to the time of the writing of the book. The author pulls together results from journals, con- 
ference proceedings, government publications, and standards documents and organizes 
these into a comprehensive and comprehensible survey. Another worthwhile and detailed 
survey is [MENE97]. A rigorous mathematical treatment is [STINO6]. 

The foregoing references provide coverage of public-key as well as symmetric encryption. 

Perhaps the most detailed description of DES is [SIMO95]; the book also contains an 
extensive discussion of differential and linear cryptanalysis of DES. [BARK91] provides a 
readable and interesting analysis of the structure of DES and of potential cryptanalytic 
approaches to DES. [EFF98] details the most effective brute-force attack on DES. [COPP94] 
looks at the inherent strength of DES and its ability to stand up to cryptanalysis. The reader 
may also find the following document useful: “The DES Algorithm Illustrated” by J. Orlin 
Grabbe, which is available at this book’s Web site. An excellent description of linear and 
differential cryptanalysis is in [HEYS02]. 


BARK91 Barker, W. Introduction to the Analysis of the Data Encryption Standard 
(DES). Laguna Hills, CA: Aegean Park Press, 1991. 

COPP94 Coppersmith, D. “The Data Encryption Standard (DES) and Its Strength 
Against Attacks.” [BM Journal of Research and Development, May 1994. 

EFF98_ Electronic Frontier Foundation. Cracking DES: Secrets of Encryption Research, 
Wiretap Politics, and Chip Design. Sebastopol, CA: O’Reilly, 1998. 


HEYS02 Heys, H. “A Tutorial on Linear and Differential Cryptanalysis.” Cryptologia, 
July 2002. 

MENE97 Menezes, A.; van Oorschot, P.; and Vanstone, S. Handbook of Applied 
Cryptography. Boca Raton, FL: CRC Press, 1997. 
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SCHN96_ Schneier, B. Applied Cryptography. New York: Wiley, 1996. 


SIMO95_ Simovits, M. The DES: An Extensive Documentation and Evaluation. Laguna 
Hills, CA: Aegean Park Press, 1995. 


STIN06 Stinson, D. Cryptography: Theory and Practice. Boca Raton, FL: Chapman & 
Hall, 2006. 


Recommended Web Site: 
e Block Cipher Hospital: Contains links to papers and theses on block cipher cryptanalysis. 


3.8 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


avalanche effect diffusion product cipher 
block cipher Feistel cipher reversible mapping 
confusion irreversible mapping round 


Data Encryption Standard key round function 


; (DES) : linear cryptanalysis subkey 
differential cryptanalysis permutation substitution 


Review Questions 


3.1 Why is it important to study the Feistel cipher? 
3.2 What is the difference between a block cipher and a stream cipher? 
3.3. Why is it not practical to use an arbitrary reversible substitution cipher of the kind 
shown in Table 3.1? 
3.4. What is a product cipher? 
3.5 What is the difference between diffusion and confusion? 
3.6 Which parameters and design choices determine the actual algorithm of a Feistel cipher? 
3.7 What is the purpose of the S-boxes in DES? 
3.8 Explain the avalanche effect. 
3.9 What is the difference between differential and linear cryptanalysis? 
Problems 


3.1 a. In Section 3.1, under the subsection on the motivation for the Feistel cipher 
structure, it was stated that, for a block of n bits, the number of different 
reversible mappings for the ideal block cipher is 2”!. Justify. 

b. In that same discussion, it was stated that for the ideal block cipher, which allows all 
possible reversible mappings, the size of the key isn X 2” bits. But, if there are 2”! 
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imo) 
: 
N 


uo 
tue 


possible mappings, it should take log, 2”! bits to discriminate among the different 
mappings, and so the key length should be log, 2”!. However, log, 2”! <n X 2”. 
Explain the discrepancy. 
Consider a Feistel cipher composed of sixteen rounds with a block length of 128 bits 
and a key length of 128 bits. Suppose that, for a given k, the key scheduling algorithm 
determines values for the first eight round keys, ky, ky,...kg, and then sets 


ky = kg, ky = ky, ky Ke---skig = ky 


Suppose you have a ciphertext c. Explain how, with access to an encryption oracle, 

you can decrypt c and determine m using just a single oracle query. This shows that 

such a cipher is vulnerable to a chosen plaintext attack. (An encryption oracle can be 

thought of as a device that, when given a plaintext, returns the corresponding cipher- 

text. The internal details of the device are not known to you and you cannot break 

open the device. You can only gain information from the oracle by making queries to 

it and observing its responses.) 

Consider a block encryption algorithm that encrypts blocks of length n, and let N = 2”. 

Say we have f plaintext—ciphertext pairs P;, C; = E(K, P;), where we assume that the 

key K selects one of the N! possible mappings. Imagine that we wish to find K by exhaus- 

tive search. We could generate key K' and test whether C; = E(K', P;) for1 =i = t.If 

K’ encrypts each P; to its proper C;, then we have evidence that K = K'. However, it may 

be the case that the mappings E(K, -) and E(K’, -) exactly agree on the ¢ plaintext— 

cipher text pairs P;, C; and agree on no other pairs. 

a. What is the probability that E(K, -) and E(K’, -) are in fact distinct mappings? 

b. What is the probability that E(K,-) and E(K’,-) agree on another ¢’ plaintext- 
ciphertext pairs where 0 = ?’ = N - 1? 

Let 7 be a permutation of the integers 0, 1,2, ...,(2” — 1), such that 7(m) gives the 

permuted value of m,0 = m < 2”. Put another way, 7 maps the set of n-bit integers 

into itself and no two integers map into the same integer. DES is such a permutation 

for 64-bit integers. We say that 7 has a fixed point at m if 7(m) = m.That is, if 7 is an 

encryption mapping, then a fixed point corresponds to a message that encrypts to 

itself. We are interested in the probability that 7 has no fixed points. Show the some- 

what unexpected result that over 60% of mappings will have at least one fixed point. 

Consider the substitution defined by row 1 of S-box S; in Table 3.3. Show a block dia- 

gram similar to Figure 3.2 that corresponds to this substitution. 

Compute the bits number 1, 16, 33, and 48 at the output of the first round of the DES 

decryption, assuming that the ciphertext block is composed of all ones and the exter- 

nal key is composed of all ones. 

Suppose the DES F function mapped every 32-bit input R, regardless of the value of 

the input K, to 

a. 32-bit string of ones 

b. bitwise complement of R 

Hint: Use the following properties of the XOR operation: 

1. What function would DES then compute? 

2. What would the decryption look like? 


(ASB)®BC=APB(BEC) 
A®A=0 
A®O0=A 

A @1 = bitwise complement of A 


where 
A,B,C are n-bit strings of bits 
0 is an n-bit string of zeros 
Lis an n-bit string of one 
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3.8 This problem provides a numerical example of encryption using a one-round version 


of DES. We start with the same bit pattern for the key K and the plaintext, namely: 
Hexadecimal notation: 0123456789ABCDEF 
Binary notation: 0000 0001 0010 0011 0100 0101 0110 0111 

1000 1001 1010 1011 1100 1101 1110 1111 


a. Derive K,, the first-round subkey. 

b. Derive Lo, Ro. 

c. Expand Rp to get E[Ro], where E[-] is the expansion function of Table 3.2. 

d. Calculate A = E[Ro] @ Kj. 

e. Group the 48-bit result of (d) into sets of 6 bits and evaluate the corresponding 
S-box substitutions. 

f. Concatenate the results of (e) to get a 32-bit result, B. 

g. Apply the permutation to get P(B). 

h. Calculate R; = P(B) @ Lo. 

i. Write down the ciphertext. 

Show that DES decryption is, in fact, the inverse of DES encryption. 

The 32-bit swap after the sixteenth iteration of the DES algorithm is needed to make 

the encryption process invertible by simply running the ciphertext back through the 

algorithm with the key order reversed. This was demonstrated in Problem 3.7. 

However, it still may not be entirely clear why the 32-bit swap is needed. To demon- 

strate why, solve the following exercises. First, some notation: 


A\B = the concatenation of the bit strings A and B 

T(R\|L) = the transformation defined by the ith iteration of the encryption 
algorithm for 1 = J = 16 

TD,(R\|L) = the transformation defined by the ith iteration of the encryption 
algorithm for 1 = J = 16 


T,7(R\|L) = L||R, where this transformation occurs after the sixteenth iteration 


of the encryption algorithm 


a. Show that the composition TD ,(IPUP7!(T\7(T,6(L1s||R1s))))) is equivalent to the 
transformation that interchanges the 32-bit halves, L1; and Rj. That is, show that 


TD, (UIPUP (Ti Ti6(LislRis))))) = RislLas 


b. Now suppose that we did away with the final 32-bit swap in the encryption algo- 
rithm. Then we would want the following equality to hold: 


TD, (IPUP '(Ty6(LislRis)))) = Lysl|Ris 


Does it? 

Compare the initial permutation table (Table 3.2a) with the permuted choice one 

table (Table 3.4b). Are the structures similar? If so, describe the similarities. What 

conclusions can you draw from this analysis? 

When using the DES algorithm for decryption, the 16 keys (Kj, Ko, ..., Ki) are 

used in reverse order. Therefore, the right-hand side of Figure 3.5 is not valid for 

decryption. Design a key-generation scheme with the appropriate shift schedule 

(analogous to Table 3.4d) for the decryption process. 

a. Let X’ be the bitwise complement of X. Prove that if the complement of the plain- 
text block is taken and the complement of an encryption key is taken, then the 
result of DES encryption with these values is the complement of the original 
ciphertext. That is, 
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If Y = E(K,X) 
Then Y’ = E(K’, X’) 


Hint: Begin by showing that for any two bit strings of equal length, A and B, 
(AGB) = A' OB. 
b. It has been said that a brute-force attack on DES requires searching a key space 
of 2°° keys. Does the result of part (a) change that? 
Show that in DES the first 24 bits of each subkey come from the same subset of 28 
bits of the initial key and that the second 24 bits of each subkey come from a disjoint 
subset of 28 bits of the initial key. 
For any block cipher, the fact that it is a nonlinear function is crucial to its security. To 
see this, suppose that we have a linear block cipher EL that encrypts 128-bit blocks of 
plaintext into 128-bit blocks of ciphertext. Let EL (k, m) denote the encryption of a 
128-bit message m under a key k (the actual bit length of k is irrelevant). Thus, 


EL(k,[m,® m]) = EL(k,m,) ® EL(k,mz) for all 128-bit patterns my, m2 


Describe how, with 128 chosen ciphertexts, an adversary can decrypt any ciphertext 
without knowledge of the secret key k. (A “chosen ciphertext” means that an adversary 
has the ability to choose a ciphertext and then obtain its decryption. Here, you have 128 
plaintext/ciphertext pairs to work with and you have the ability to chose the value of the 
ciphertexts.) 


ll 


Note: The following problems refer to simplified DES, described in Appendix G. 


3.16 


Refer to Figure G.2, which depicts key generation for S-DES. 

a. How important is the initial PLO permutation function? 

b. How important are the two LS-1 shift functions? 

The equations for the variables q and r for S-DES are defined in the section on 
S-DES analysis. Provide the equations for s and f. 

Using S-DES, decrypt the string (10100010) using the key (0111111101) by hand. 
Show intermediate results after each function (IP, Fx, SW, Fx, IP"). Then decode the 
first 4 bits of the plaintext string to a letter and the second 4 bits to another letter where 
we encode A through P in base 2 (i-e., A = 0000, B = 0001,..., P = 1111). Hint: As a mid- 
way check, after the application of SW, the string should be (00010011). 


Programming Problems 


3.19 


3.20 


Create software that can encrypt and decrypt using a general substitution block 
cipher. 

Create software that can encrypt and decrypt using S-DES. Test data: use plaintext, 
ciphertext, and key of Problem 3.18. 
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The next morning at daybreak, Star flew indoors, seemingly keen for a lesson. 
I said, “Tap eight.” She did a brilliant exhibition, first tapping it in 4, 4, then giving 
me a hasty glance and doing it in 2, 2, 2, 2, before coming for her nut. 

It is astonishing that Star learned to count up to 8 with no difficulty, and of 
her own accord discovered that each number could be given with various differ- 
ent divisions, this leaving no doubt that she was consciously thinking each num- 
ber. In fact, she did mental arithmetic, although unable, like humans, to name the 
numbers. But she learned to recognize their spoken names almost immediately 
and was able to remember the sounds of the names. Star is unique as a wild bird, 
who of her own free will pursued the science of numbers with keen interest and 
astonishing intelligence. 


—Living with Birds, Len Howard 


KEY POINTS 


® Modular arithmetic is a kind of integer arithmetic that reduces all numbers 


to one of a fixed set [0,..., — 1] for some number n. Any integer outside 
this range is reduced to one in this range by taking the remainder after divi- 
sion by n. 


® The greatest common divisor of two integers is the largest positive integer 
that exactly divides both integers. 


® A field is a set of elements on which two arithmetic operations (addition and 
multiplication) have been defined and which has the properties of ordinary 
arithmetic, such as closure, associativity, commutativity, distributivity, and 
having both additive and multiplicative inverses. 


© Finite fields are important in several areas of cryptography. A finite field is 
simply a field with a finite number of elements. It can be shown that the 
order of a finite field (number of elements in the field) must be a power of 
a prime p”, where vis a positive integer. 

® Finite fields of order p can be defined using arithmetic mod p. 


® Finite fields of order p”, for n>1, can be defined using arithmetic over 
polynomials. 


Finite fields have become increasingly important in cryptography. A number of crypto- 
graphic algorithms rely heavily on properties of finite fields, notably the Advanced 
Encryption Standard (AES) and elliptic curve cryptography. Other examples include 
the message authentication code CMAC and the authenticated encryption scheme 
GMC. 

This chapter provides the reader with sufficient background on the concepts 
of finite fields to be able to understand the design of AES and other cryptographic 
algorithms that use finite fields. The first three sections introduce basic concepts 
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from number theory that are needed in the remainder of the chapter; these 
include divisibility, the Euclidian algorithm, and modular arithmetic. Next comes a 
brief overview of the concepts of group, ring, and field. This section is somewhat 
abstract; the reader may prefer to quickly skim this section on a first reading. We 
are then ready to discuss finite fields of the form GF(p), where p is a prime num- 
ber. Next, we need some additional background, this time in polynomial arith- 
metic. The chapter concludes with a discussion of finite fields of the form GF(2”), 
where nis a positive integer. 

The concepts and techniques of number theory are quite abstract, and it is often 
difficult to grasp them intuitively without examples. Accordingly, this chapter and 
Chapter 8 include a number of examples, each of which is highlighted in a shaded box. 


4.1 DIVISIBILITY AND THE DIVISION ALGORITHM 
Divisibility 
We say that a nonzero b divides a if a = mb for some m, where a, b, and m are 


integers. That is, b divides a if there is no remainder on division. The notation bla is 
commonly used to mean b divides a. Also, if b|a, we say that b is a divisor of a. 


The positive divisors of 24 are 1,2, 3,4, 6, 8,12, and 24. 


13|182; —5|30; 17|289; —3|33; 17|0 


Subsequently, we will need some simple properties of divisibility for integers, 
which are as follows: 


e Ifall,thena = +1. 

e Ifal|b and bla, then a = +b. 
e Any b # 0 divides 0. 

e Ifalb and dlc, then alc: 


11/66 and 66/198 = 11|198 


e If blg and b\h, then b|(mg + nh) for arbitrary integers m and n. 
To see this last point, note that 


e If blg, then gis of the form g = b X g, for some integer gy. 
e If bh, then h is of the form h = b X h, for some integer hy. 


So 
mg + nh = mbg, + nbh, = b X (mg, + nh,) 
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and therefore b divides mg + nh. 


b=7;g = 14;h = 63;m = 3;n = 2 
7|14 and 7|63. 


To show 7|(3 X 14 + 2 x 63), 
we have (3 X 14 + 2 X 63) = 7(3 X24+2 X 9), 
and it is obvious that 7|(7(3 X 2 + 2 x 9)). 


The Division Algorithm 


Given any positive integer n and any nonnegative integer a, if we divide a by n, we 
get an integer quotient g and an integer remainder r that obey the following rela- 
tionship: 


a=qntr 0=r<njq=|aln| (4.1) 


where | x | is the largest integer less than or equal to x. Equation (4.1) is referred to 
as the division algorithm.! 

Figure 4.1a demonstrates that, given a and positive n,it is always possible to 
find g and r that satisfy the preceding relationship. Represent the integers on the 
number line; a will fall somewhere on that line (positive a is shown, a similar 
demonstration can be made for negative a). Starting at 0, proceed to n, 2n, up to 
qn, such that gn = a and(q + 1)n > a. The distance from qn to a is r, and we 
have found the unique values of g and r. The remainder r is often referred to as a 
residue. 


n 2n 3n qn a (q+1)n 


(a) General relationship r 


0 15 30 45 60 70 75 
=2x15 =3x15 =4x15 =5x15 
(b) Example: 70 = (4x15) + 10 10 


Figure 4.1 The Relationship a=qn+r;0<r<n 


'Bquation 4.1 expresses a theorem rather than an algorithm, but by tradition, this is referred to as the 
division algorithm. 
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= 11; n=7; 11=1xX7+4; r=4 q=1 
Sl ne (2) xa 38 3g 7 


Figure 4.1b provides another example. 


4.2 THE EUCLIDEAN ALGORITHM 


One of the basic techniques of number theory is the Euclidean algorithm, which is a 
simple procedure for determining the greatest common divisor of two positive integers. 
First, we need a simple definition: Two integers are relatively prime if their only 
common positive integer factor is 1. 


Greatest Common Divisor 


Recall that nonzero b is defined to be a divisor of aif a = mb for some m, where a, b, 
and m are integers. We will use the notation gcd(a, b) to mean the greatest common 
divisor of a and b. The greatest common divisor of a and 5 is the largest integer that 
divides both a and b. We also define gced(0, 0) = 0. 

More formally, the positive integer c is said to be the greatest common divisor 
of a and 5 if 


1. cis a divisor of a and of b. 
2. Any divisor of a and b is a divisor of c. 


An equivalent definition is the following: 
gcd(a, b) = max[k, suchthatkla and k|b] 


Because we require that the greatest common divisor be positive, gcd(a, b) = 
gcd(a, —b) = gcd(—a, b) = gced(—a,—b). In general, ged(a, b) = gcd(\al, |b). 


gcd(60, 24) = gced(60, —24) = 12 


Also, because all nonzero integers divide 0, we have gcd(a, 0) = |al. 

We stated that two integers a and D are relatively prime if their only common 
positive integer factor is 1. This is equivalent to saying that a and Db are relatively 
prime if gcd(a, b) = 1. 


Finding the Greatest Common Divisor 


We now describe an algorithm credited to Euclid for easily finding the greatest 
common divisor of two integers. This algorithm has significance subsequently in 
this chapter. Suppose we have integers a, b such that d = gcd(a, b). Because 
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gcd(la|, |b]) = gcd(a, b), there is no harm in assuming a = b > 0. Now dividing a 
by b and applying the division algorithm, we can state: 


a=qb+n 0=s=7<b (4.2) 


If it happens that r, = 0, then b|a and d = gcd(a, b) = b. But if r, 4 0, we can state 
that d|r,. This is due to the basic properties of divisibility: the relations dla and d|b 
together imply that d|(a — q,b), which is the same as d|r,. Before proceeding with the 
Euclidian algorithm, we need to answer the question: What is the gcd(b, r,;)? We know 
that d|b and d|r,. Now take any arbitrary integer c that divides both b and 7. 
Therefore, c|(q;b + r,) = a. Because c divides both a and b, we must have c < d, 
which is the greatest common divisor of a and b. Therefore d = gcd(b, 7). 

Let us now return to Equation (4.2) and assume that 7, # 0. Because b > 1, 
we can divide b by 7, and apply the division algorithm to obtain: 


b=qnit+h 0Osn<n 


As before, if m = 0, then d = r, and if m 4 0, then d = gcd(n, m). The division 
process continues until some zero remainder appears, say, at the (n + 1)th stage 
where 7, is divided by 1,,. The result is the following system of equations: 


a=qb+n 0<n<b 
b=qrit+hn 0<n<n 
N= Gath 0<KR<nh 
e ©. (4.3) 
Tn-2 = Anln-1 Bis Ty 0< Th < Th-1 


Tr-1 = Qn+iln +0 
d = gcd(a, b) = nr, 


At each iteration, we have d = gcd(7, 7;4,) until finally d = gcd(r,, 0) = 1%. 
Thus, we can find the greatest common divisor of two integers by repetitive 
application of the division algorithm. This scheme is known as the Euclidean 
algorithm. 

We have essentially argued from the top down that the final result is the 
gcd(a, b). We can also argue from the bottom up. The first step is to show that 
r, divides a and b. It follows from the last division in Equation (4.3) that 
r, divides r,_;. The next to last division shows that r, divides r,. because it 
divides both terms on the right. Successively, one sees that 7, divides all 7;’s and 
finally a and b. It remains to show that +, is the largest divisor that divides a and 
b. If we take any arbitrary integer that divides a and b, it must also divide 1, as 
explained previously. We can follow the sequence of equations in Equation (4.3) 
down and show that c must divide all r,s. Therefore c must divide r,, so that 
Tt = gced(a, b). 
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Let us now look at an example with relatively large numbers to see the power 
of this algorithm: 


a=qb +r, | 1160718174 = 3 X 316258250 + 211943424 | d = gcd(316258250, 
211943424) 


b= qr +h 316258250 = 1 X 211943424 + 104314826 | d = gcd(211943424, 
104314826) 


= gary + r3 | 211943424 = 2 x 104314826 + 3313772 | d = gcd(104314826, 
3313772) 


= quar; + ry, | 104314826 = 31 x 3313772 + 1587894 | d = gcd(3313772, 
1587894) 


= qsrs + 15 3313772 = 2X 1587894 + 137984 | d = gcd(1587894, 
137984) 


= gers 4 1587894 = 11 X 137984 4 70070 | d = gcd(137984,70070) 
= gars 4 137984 = 1 x 70070 4 67914 | d = gcd(70070,67914) 
= gery 4 70070= 1X 67914 4 2156 | d = gcd(67914, 2156) 

= gorg + 67914= 31x 25164 1078 | d = gcd(2156, 1078) 

= gore 4 2156 = 2 x 1078 4 0 | d = gcd(1078, 0) = 1078 


Therefore, d = gcd(1160718174, 316258250) = 1078 


In this example, we begin by dividing 1160718174 by 316258250, which gives 3 
with a remainder of 211943424. Next we take 316258250 and divide it by 211943424. 
The process continues until we get a remainder of 0, yielding a result of 1078. 

It will be helpful in what follows to recast the above computation in tabular form. 
For every step of the iteration, we have 7,_, = gj”, + 7, where r;_, is the dividend, 7;_; 
is the divisor, g; is the quotient, and 7; is the remainder. Table 4.1 summarizes the results. 


Table 4.1 Euclidean Algorithm Example 


Dividend Divisor Quotient Remainder 


1160718174 316258250 n= r, = 211943424 
316258250 211943434 q = ry = 104314826 


= 211943424 = 104314826 = r3 = 3313772 


104314826 3 = 3313772 = rg = 1587894 


3313772 1587894 = rs = 137984 


1587894 = 137984 = = 70070 


137984 = 70070 = y= 67914 


70070 = 67914 = rg = 2156 


67914 = 2156 = to = 1078 


2156 = 1078 no = 0 
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4.3 MODULAR ARITHMETIC 


The Modulus 


If a is an integer and n is a positive integer, we define a mod n to be the remainder 
when a is divided by n. The integer n is called the modulus. Thus, for any integer a, 
we can rewrite Equation (4.1) as follows: 


a= qnt+r 0O=r<nq= lan 


a= |aln| Xn + (amodn) 


11 mod 7 = 4; —11mod7 =3 


Two integers a and b are said to be congruent modulo n, if (a modn) = 
(b mod n). This is written as a = b (modn).” 


73 = 4 (mod 23); 21 = —9 (mod 10) 


Note that if a = 0 (mod n), then nla. 


Properties of Congruences 
Congruences have the following properties: 
1. a = b(modn) if n|(a — b). 
2. a = b (mod n) implies b = a (mod n). 
3. a = b(modn) and b = c (mod n) imply a = c (mod n). 
To demonstrate the first point, if n|(a — b), then (a — b) = kn for some k. 


So we can write a = b + kn. Therefore, (a mod n) = (remainder when b + knis 
divided by n) = (remainder when b is divided by n) = (6 mod n). 


23 = 8 (mod5) because 23 —-8=15=5 x3 
—11 =5(mod8) because —11 —5 = —16 =8 X (-2) 


81 = 0(mod27) because 81 — 0 = 81 = 27 x3 


The remaining points are as easily proved. 


Modular Arithmetic Operations 


Note that, by definition (Figure 4.1), the (mod ) operator maps all integers into the set 
of integers {0, 1, ..., (” — 1)}. This suggests the question: Can we perform arithmetic 


2We have just used the operator mod in two different ways: first as a binary operator that produces a 
remainder, as in the expression a mod b; second as a congruence relation that shows the equivalence of 
two integers, as in the expression a = b(mod n). See Appendix 4A for a discussion. 
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operations within the confines of this set? It turns out that we can; this technique is 
known as modular arithmetic. 
Modular arithmetic exhibits the following properties: 
. [(@modn) + (bmodn)] modn = (a + b)modn 
- [(amodn) — (bmodn)] modn = (a — b) modn 
- [((amodn) X (b mod n)] modn = (a X b) modn 


Q do = 


We demonstrate the first property. Define (a mod n) = r, and (b mod n) = nh. 
Then we can write a = r, + jn for some integer j and b = n, + kn for some integer 


k. Then 
(a + b)modn = (r, + jn + ry, + kn) modn 
= (rg + rp + (k + j)n) modn 
= (r, + ry) modu 
= [(amodn) + (bmodn)|modn 


The remaining properties are proven as easily. Here are examples of the three 
properties: 


11 mod 8 = 3;15 mod8 = 7 
[(11 mod 8) + (15 mod 8)] mod 8 = 10 mod 8 = 2 
(11 + 15) mod 8 = 26 mod 8 = 2 


[(11 mod 8) — (15 mod 8)] mod 8 = —4 mod 8 = 4 
(11 — 15) mod 8 = —4 mod 8 = 4 


[(11 mod 8) X (15 mod 8)] mod 8 = 21 mod 8 = 5 
(11 X 15) mod 8 = 165 mod 8 = 5 


Exponentiation is performed by repeated multiplication, as in ordinary arith- 
metic. (We have more to say about exponentiation in Chapter 8.) 


To find 11’ mod 13, we can proceed as follows: 
11 = 121 = 4 (mod13) 
114 = (11°)? = 4? = 3 (mod13) 
11’ = 11 x 4 x 3 = 132 = 2 (mod13) 


Thus, the rules for ordinary arithmetic involving addition, subtraction, and 
multiplication carry over into modular arithmetic. 

Table 4.2 provides an illustration of modular addition and multiplication 
modulo 8. Looking at addition, the results are straightforward, and there is a regular 
pattern to the matrix. Both matrices are symmetric about the main diagonal in 
conformance to the commutative property of addition and multiplication. As in 
ordinary addition, there is an additive inverse, or negative, to each integer in modu- 
lar arithmetic. In this case, the negative of an integer x is the integer y such that 
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Table 4.2 Arithmetic Modulo 8 


+ 0 1 2 3 4 5 6 7 

0 0 1 2 3 4 5 6 7 

1 1 2 3 4 a 6 7 0 

2 2 ) 4 a 6 7 0 1 

3 ) 4 Py 6 7 0 1 2 

4 4 P 6 7 0 dl 2 3 

5 Py 6 y) 0 a 2 3 4 

6 6 7 0 1 2 3 4 5 

: 

(a) Addition modulo 8 

x 4 5 6 

0 0 0 0 

| 
2 0 0 2 4 

3 0 4 7 2 

4 0 0 4 0 

S) 0 4 1 6 

6 0 0 6 4 

7 0 4 3 2 


(b) Multiplication modulo 8 (c) Additive and multiplicative 
inverses modulo 8 


(x + y) mod 8 = 0.To find the additive inverse of an integer in the left-hand column, 
scan across the corresponding row of the matrix to find the value 0; the integer at 
the top of that column is the additive inverse; thus, (2 + 6) mod 8 = 0. Similarly, the 
entries in the multiplication table are straightforward. In ordinary arithmetic, there 
is a multiplicative inverse, or reciprocal, to each integer. In modular arithmetic mod 8, 
the multiplicative inverse of x is the integer y such that (x X y) mod 8 = 1 mod 8. 
Now, to find the multiplicative inverse of an integer from the multiplication table, 
scan across the matrix in the row for that integer to find the value 1; the integer at 
the top of that column is the multiplicative inverse; thus, (3 X 3) mod 8 = 1. Note 
that not all integers mod 8 have a multiplicative inverse; more about that later. 


Properties of Modular Arithmetic 
Define the set Z,, as the set of nonnegative integers less than n: 
Zn = {0, 1, vexg (il ~~ 1)} 


This is referred to as the set of residues, or residue classes (mod 1). To be more 
precise, each integer in Z,, represents a residue class. We can label the residue classes 
(mod n)as[0], [1], [2], ...,[” — 1], where 


[r] = {a: ais an integer, a = r(modn)} 
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The residue classes (mod 4) are 


soog HIG, —12, =8, 45, W, 4h, 12, 1K, 320} 


nog By ll 7, sh I SSN cael 
poog Nh 10), =@, =2, (6, 11), 4h I, ceo} 
soog =, —O, =5, =1,3, % Wil, 1S, 19, o 20} 


Of all the integers in a residue class, the smallest nonnegative integer is the 
one used to represent the residue class. Finding the smallest nonnegative integer to 
which k is congruent modulo n is called reducing k modulo n. 

If we perform modular arithmetic within Z,,, the properties shown in Table 4.3 
hold for integers in Z,,. We show in the next section that this implies that Z,, is a com- 
mutative ring with a multiplicative identity element. 

There is one peculiarity of modular arithmetic that sets it apart from ordinary 
arithmetic. First, observe that (as in ordinary arithmetic) we can write the following: 


if (a + b) = (a+ c)(modn) then b = c (modn) (4.4) 


(S ap 23) = (6 3 7) (Gneals), 23) = Wmoals)) 


Equation (4.4) is consistent with the existence of an additive inverse. Adding 
the additive inverse of a to both sides of Equation (4.4), we have 


((-a) + a + b) = ((—a) + a + c)(mod n) 
b = c (mod n) 


However, the following statement is true only with the attached condition: 
if (a X b) = (a X c)(mod n) then b = c(mod n) if ais relatively prime to n (4.5) 


Recall that two integers are relatively prime if their only common positive integer 
factor is 1. Similar to the case of Equation (4.4), we can say that Equation (4.5) is 


Table 4.3 Properties of Modular Arithmetic for Integers in Z,, 


Property Expression 


F (w + x) modn = (x + w) moda 
Commutative Laws 
(w X x) modn = (x + w) moda 


[(w + x) + y] modn = [w + (x + y)] modn 
[(w X x) X y] modn = [w X (x X y)] modn 


Associative Laws 


Distributive Law [w X (x + y)] modn = [(w X x) + (w X y)] modn 


ae (0 + w) modn = wmodn 
Identities 


(1 X w) modn = w modn 


Additive Inverse (-w) For each w e€ Z,,, there exists a a z such that w + z = 0modn 


112 CHAPTER 4 / BASIC CONCEPTS IN NUMBER THEORY AND FINITE FIELDS 
consistent with the existence of a multiplicative inverse. Applying the multiplicative 
inverse of a to both sides of Equation (4.5), we have 


((a~!)ab) = ((a~)ac)(modn) 
b = c(modn) 


To see this, consider an example in which the condition of Equation (4.5) does 
not hold. The integers 6 and 8 are not relatively prime, since they have the 
common factor 2. We have the following: 


6x3 = 18 
6 X 7 = 42 = 2(mod8) 


Yet3 4 7 (mod 8): 


The reason for this strange result is that for any general modulus n, a multiplier a 
that is applied in turn to the integers 0 through (m — 1) will fail to produce a complete 
set of residues if a and v have any factors in common. 


With a = 6 andn = 8, 


Ze 0 1 2 
Multiplyby6 0 6 12 
Residues 0 6 4 2, 0 6 4 2, 


Because we do not have a complete set of residues when multiplying by 6, 
more than one integer in Zg maps into the same residue. Specifically, 
6 X 0Omod8 = 6 X 4mod 8; 6 X 1 mod 8 = 6 X 5 mod8; and so on. Because 
this is a many-to-one mapping, there is not a unique inverse to the multiply 
operation. 

However, if we take a = 5 andn = 8, whose only common factor is 1, 


Zig (ee ae aoe 


Multiplyby5 O 5 10 15 20 25 30 35 
Residues QO 5 2 YF a 1 @ 3 


The line of residues contains all the integers in Zg, in a different order. 


In general, an integer has a multiplicative inverse in Z,, if that integer is relatively 
prime to n. Table 4.2c shows that the integers 1,3,5, and 7 have a multiplicative inverse 
in Zg; but 2, 4, and 6 do not. 


Euclidean Algorithm Revisited 


The Euclidean algorithm can be based on the following theorem: For any nonnegative 
integer a and any positive integer b, 


gcd(a, b) = gcd(b,a mod b) (4.6) 
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gcd(55, 22) = ged(22,55 mod 22) = ged(22,11) = 11 


To see that Equation (4.6) works, let d = gcd(a, b). Then, by the definition of 
gcd, d|a and d|b. For any positive integer b, we can express a as 


a=kb+r=r(modb) 
amodb=r 


with k, r integers. Therefore, (a mod b) = a — kb for some integer k. But because d | b, it 
also divides kb. We also have d | a. Therefore, d | (a mod b). This shows that d is a common 
divisor of b and (a mod b). Conversely, if d is a common divisor of b and (a mod b), then 
d| kb and thus d|[kb + (a mod b)], which is equivalent to d | a.Thus, the set of common 
divisors of a and b is equal to the set of common divisors of b and (a mod b). Therefore, the 
gcd of one pair is the same as the gcd of the other pair, proving the theorem. 

Equation (4.6) can be used repetitively to determine the greatest common divisor. 


gcd(18, 12) = ged(12, 6) = gced(6, 0) = 6 
gcd(11, 10) = gced(10, 1) = ged(1, 0) = 1 


This is the same scheme shown in Equation (4.3), which can be rewritten in the 
following way. 


Euclidean Algorithm 
Calculate Which satisfies 


r, = amodb a=qb+n 


ry = bmodr, b= qo} a Ty 


r3 = ry; modr, N= Q@lo t 13 


Tn = Tn-2 mod Tn-1 Tn-2 = Wn" n-1 si ln 


Tn+1 = Tn-1modr, = 0 Tn-1 = Qn+t"n + 0 
d= gcd(a,b) =r, 


We can define the Euclidean algorithm concisely as the following recursive 
function. 
Euclid(a,b) 

if (b=0) then return a; 

else return Euclid(b, a mod b); 


The Extended Euclidean Algorithm 


We now proceed to look at an extension to the Euclidean algorithm that will be impor- 
tant for later computations in the area of finite fields and in encryption algorithms, 
such as RSA. For given integers a and b, the extended Euclidean algorithm not only 
calculate the greatest common divisor d but also two additional integers x and y that 
satisfy the following equation. 


114 
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ax + by = d= gcd(a, b) (4.7) 


It should be clear that x and y will have opposite signs. Before examining the 
algorithm, let us look at some of the values of x and y when a = 42 and b = 30. 
Note that gcd(42, 30) = 6. Here is a partial table of values* for 42x + 30y. 


Observer that all of the entries are divisible by 6. This is not surprising, 
because both 42 and 30 are divisible by 6, so every number of the form 
42x + 30y = 6(7x + Sy) isa multiple of 6. Note also that gced(42, 30) = 6 appears 
in the table. In general, it can be shown that for given integers a and 5, the smallest 
positive value of ax + by is equal to gced(a, b). 

Now let us show how to extend the Euclidean algorithm to determine (x, y, d) 
given a and b. We again go through the sequence of divisions indicated in Equation 
(4.3), and we assume that at each step 7 we can find integers x; and y; that satisfy 
1; = ax; + by;.We end up with the following sequence. 


a=qb+n r= ax, + by, 
b=qrit+hn Th = aXx7 + byy 
N= Gln + 13 rz = ax3 + by 


Tn-2 = Qnln-1 Fy My = aX, + by, 
Mm-1 = An+i"n 0 
Now, observe that we can rearrange terms to write 
t= oo ~ head (4.8) 
Also, in rows i — 1 andi — 2, we find the values 


i; = ax; + by;_ and Ti. = axj;_-1 + by;-1 


Substituting into Equation (4.8), we have 


1 = (axj-2 + by;-2) — (axi-1 + byj-1)4i 
= ag ~ O2)-1) + D2 G4) 


3This example is taken from [SILV06]. 


But we have already assumed that 7; = 


Xj = Xi-2 ~ QiXi-1 
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ax; + by,.Therefore, 


and y; = yi-2 — Qi-1 


We now summarize the calculations: 
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Extended Euclidean Algorithm 


Calculate Which satisfies Calculate Which satisfies 
r4=a x, =1;y_, =0 a = ax_, + by_, 
ro = b Xo = Oyo = 1 b = axy + by 
r; = amodb a=qbt+n Xy = X14 - MX = 1 ry = ax, + by; 
qi = [alb| V1 = Y-1— Yo =H 
r, = bmodr, b = Gr, + X_ = Xy — Gox1 In = aX, + by, 
q2 = [bir | Y2 = Yo 1 
r3 = ry mod ry ry = Q3lo + 13 Xz = Xy — G3Xr r3 = ax; + bys 
43 = | nro | Y3 = Yi ~ 43y2 


Th = Tn-2 mod Tn-1 
dn = | Tn—-2/Tn—3 | 


Tn-2 = Ql n-1 + Tn 


Xn = Xn-2 ~ FnXn-1 
Yn = Yn-2 ~ WnYn-1 


Ty, = ax, + by, 


= r,-,;modr, = 0 
| ?n—-1/Tn-2 | 


Tht 
Qn+1 = 


Tn-1 = @n+iln + 0 


d = ged(a, b) = r, 


xX = Xn V = Vn 


We need to make several additional comments here. In each row, we calculate 
a new remainder 7; based on the remainders of the previous two rows, namely 7;_, 
and 7;_7. To start the algorithm, we need values for 7 and r_,, which are just a and b. 
It is then straightforward to determine the required values for x_;, y_1, Xp, and yo. 

We know from the original Euclidean algorithm that the process ends with a 
remainder of zero and that the greatest common divisor of a and Db is 
r,. But we also have determined that d =r, = ax, + by,. 
Therefore, in Equation (4.7), x = x, and y = y,. 

As an example, let us use a= 1759 and b=550 and solve for 
1759x + 550y = ged(1759, 550). The results are shown in Table 4.4. Thus, we have 
1759 x (-111) + 550 x 355 = -195249 + 195250 = 1. 


d = gced(a, b) = 


Table 4.4 Extended Euclidean Algorithm Example 


Result: d = 1; x 


111: y = 355 


i qi Xj Ji 
-1 1759 1 0 
0 550 0 il 
1 109 3 1 3 
2; 5 5 =) 16 
3 4 21 106 -339 
4 1 1 -111 355 
5 0 4 
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4.4 GROUPS, RINGS, AND FIELDS 


Groups, rings, and fields are the fundamental elements of a branch of mathematics 
known as abstract algebra, or modern algebra. In abstract algebra, we are concerned 
with sets on whose elements we can operate algebraically; that is, we can combine 
two elements of the set, perhaps in several ways, to obtain a third element of the set. 
These operations are subject to specific rules, which define the nature of the set. By 
convention, the notation for the two principal classes of operations on set elements 
is usually the same as the notation for addition and multiplication on ordinary num- 
bers. However, it is important to note that, in abstract algebra, we are not limited to 
ordinary arithmetical operations. All this should become clear as we proceed. 


Groups 


A group G, sometimes denoted by {G, °},is a set of elements with a binary operation 
denoted by °* that associates to each ordered pair (a, b) of elements in G an element 
(a* b) in G, such that the following axioms are obeyed:* 


(A1) Closure: If a and b belong to G, then a* b is also in G. 
(A2) Associative: a*(bec) = (a°b)°c for alla, b,cinG. 
(A3) Identity element: There is an element e in G such 


that are = e*a = aforallainG. 


(A4) Inverse element: For each a in G, there is an element a’ in G 
such that aea’ = a'*a =e. 


Let N, denote a set of n distinct symbols that, for convenience, we represent as 
{1, 2, ...,}. A permutation of 7 distinct symbols is a one-to-one mapping from N,, 
to N,.° Define S,, to be the set of all permutations of n distinct symbols. Each 
element of S,, is represented by a permutation of the integers 7 in 1, 2, ..., 7. Itis 
easy to demonstrate that S,, is a group: 


Al: If (z,p €5S,), then the composite mapping 7 ° p is formed by per- 
muting the elements of p according to the permutation z. For exam- 


ple, {3, 2, 1} * {1, 3,2} = {2,3, 1}. Clearly, 7*p &5S,. 
The composition of mappings is also easily seen to be associative. 


The identity mapping is the permutation that does not alter the 
order of the n elements. For S,,, the identity element is {1, 2, ..., n}. 
For any 7 €5S,, the mapping that undoes the permutation defined by 


a is the inverse element for 7. There will always be such an inverse. 
Ror exaumnole (2, 33, i 28, il, 2 = fil, 2 Se 


‘The operator ¢ is generic and can refer to addition, multiplication, or some other mathematical operation. 
>This is equivalent to the definition of permutation in Chapter 2, which stated that a permutation of a finite 
set of elements S is an ordered sequence of all the elements of S, with each element appearing exactly once. 
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If a group has a finite number of elements, it is referred to as a finite group, 
and the order of the group is equal to the number of elements in the group. 
Otherwise, the group is an infinite group. 

A group is said to be abelian if it satisfies the following additional condition: 


(A5) Commutative: a°b = beaforalla,binG. 


The set of integers (positive, negative, and 0) under addition is an abelian group. 
The set of nonzero real numbers under multiplication is an abelian group. The set 


S,, from the preceding example is a group but not an abelian group for n > 2. 


When the group operation is addition, the identity element is 0; the inverse 

element of a is -—a; and subtraction is defined with the following rule: 
a-—b=a+(-b). 
Cyciic Group We define exponentiation within a group as a repeated appli- 
cation of the group operator, so that a? = a*a*a. Furthermore, we define a° = e 
as the identity element, and a" = (a’)”", where a’ is the inverse element of a 
within the group. A group G is eyelic if every element of G is a power a* (k is an 
integer) of a fixed element ae G. The element a is said to generate the group G 
or to be a generator of G. A cyclic group is always abelian and may be finite or 
infinite. 


The additive group of integers is an infinite cyclic group generated by the 
element 1. In this case, powers are interpreted additively, so that n is the nth 


power of 1. 


Rings 


A ring R, sometimes denoted by {R, +, X}, is a set of elements with two binary 
operations, called addition and multiplication,® such that for all a, b, c in R the 
following axioms are obeyed. 


(A1-AS5) R is an abelian group with respect to addition; that is, R satisfies 
axioms Al through AS. For the case of an additive group, we denote 
the identity element as 0 and the inverse of a as —a. 

(M1) Closure under multiplication: If a and b belong to R, then ab is also 


in R. 
(M2) Associativity of multiplication: a(bc) = (ab)c for alla, b,c in R. 
(M3) Distributive laws: a(b + c) = ab + ac for alla, b,cin R. 


(a + b)c = ac + be for alla,b,cin R. 


In essence, a ring is a set in which we can do addition, subtraction 
[a —- b =a + (—b)], and multiplication without leaving the set. 


Generally, we do not use the multiplication symbol, x, but denote multiplication by the concatenation of 
two elements. 
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With respect to addition and multiplication, the set of all n-square matrices over 


the real numbers is a ring. 


A ring is said to be commutative if it satisfies the following additional condition: 


(M4) Commutativity of multiplication: ab = ba for alla,bin R. 


Let S be the set of even integers (positive, negative, and 0) under the usual opera- 
tions of addition and multiplication. S is a commutative ring. The set of all m-square 
matrices defined in the preceding example is not a commutative ring. 


The set Z,, of integers {0, 1, ..., — 1}, together with the arithmetic operations 
modulo n, is a commutative ring (Table 4.3). 


Next, we define an integral domain, which is a commutative ring that obeys the 
following axioms. 


(M5) Multiplicative identity: There is an element 1 in R such 
that a1 = la = aforallainR. 


(M6) No zero divisors: If a,b in R and ab = O, then either a = 0 
or b = 0. 


Let S be the set of integers, positive, negative, and 0, under the usual operations 


of addition and multiplication. $ is an integral domain. 


Fields 


A field F, sometimes denoted by {F, +, X}, is a set of elements with two binary opera- 
tions, called addition and multiplication, such that for all a, b, c in F the following 
axioms are obeyed. 


(A1-M6) F is an integral domain; that is, F satisfies axioms Al through AS and 
M1 through M6. 


(M7) Multiplicative inverse: For each a in F, except 0, there is an element 
a_'in Fsuch that aa! = (a“'Ja = 1. 


In essence, a field is a set in which we can do addition, subtraction, multiplication, 
and division without leaving the set. Division is defined with the following rule: 
alb = a(b“'). 


Familiar examples of fields are the rational numbers, the real numbers, and the 
complex numbers. Note that the set of all integers is not a field, because not 


every element of the set has a multiplicative inverse; in fact, only the elements 1 
and —1 have multiplicative inverses in the integers. 


Figure 4.2 summarizes the axioms that define groups, rings, and fields. 
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Figure 4.2 
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Groups, Ring, and Field 


(A1) Closure under addition: 
(A2) Associativity of addition: 
(A3) Additive identity: 


(A4) Additive inverse: 


(A5) Commutativity of addition: 
(M1) Closure under multiplication: 
(M2) Associativity of multiplication: 
(M3) Distributive laws: 


(M4) Commutativity of multiplication: 


(M5) Multiplicative identity: 
(M6) No zero divisors: 


(M7) Multiplicative inverse: 


If a and b belong to S, then a + b is also in S 
at+(b+c)=(a+tb)+ c foralla,b,cin$ 
There is an element 0 in R such that 
a+0=0+a=aforallainS 

For each a in S there is an element —a in S 
such that a + (—a) = (—a) +a=0 
at+b=b+4aforalla,binS 

If a and b belong to S, then ab is also in S 
a(bc) = (ab)c for all a, b, cin S 

a(b + c) = ab + ac for alla, b,cinS 

(a + b)c = ac + be for all a,b, cin S 

ab = ba for alla, bin S 

There is an element | in S such that 


al = la=aforallainS 

If a, bin S and ab = O, then either 
a=0orb=0 

If a belongs to Sanda _ 0, there is an 
element a”! in S such that aa~! = a 'a = 1 
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4.5 FINITE FIELDS OF THE FORM GF(p) 


In Section 4.4, we defined a field as a set that obeys all of the axioms of Figure 4.2 
and gave some examples of infinite fields. Infinite fields are not of particular interest 
in the context of cryptography. However, finite fields play a crucial role in many 
cryptographic algorithms. It can be shown that the order of a finite field (number of 
elements in the field) must be a power of a prime p”, where n is a positive integer. 
We discuss prime numbers in detail in Chapter 8. Here, we need only say that a 
prime number is an integer whose only positive integer factors are itself and 1. That 
is, the only positive integers that are divisors of p are p and 1. 

The finite field of order p” is generally written GF(p”); GF stands for Galois 
field, in honor of the mathematician who first studied finite fields. Two special cases 
are of interest for our purposes. For n = 1, we have the finite field GF(p); this finite 
field has a different structure than that for finite fields with n > 1 and is studied in 
this section. In Section 4.7, we look at finite fields of the form GF(2”). 


Finite Fields of Order p 
For a given prime, p, we define the finite field of order p, GF(p), as the set Z, of 


integers {0,1, ...,p — 1} together with the arithmetic operations modulo p. 
Recall that we showed in Section 4.3 that the set Z, of integers 
{0,1, ...,m — 1}, together with the arithmetic operations modulo n, is a commuta- 


tive ring (Table 4.3). We further observed that any integer in Z,, has a multiplicative 
inverse if and only if that integer is relatively prime to n [see discussion of 
Equation (4.5)]’ If vis prime, then all of the nonzero integers in Z,, are relatively prime 
to n, and therefore there exists a multiplicative inverse for all of the nonzero integers 
in Z,,. Thus, for Z, we can add the following properties to those listed in Table 4.3: 


Multiplicative inverse (w~') For each we Z,, w # 0, there exists a 
ze Z, such that w X z = 1 (modp) 


Because w is relatively prime to p, if we multiply all the elements of Z,, by w, the 
resulting residues are all of the elements of Z, permuted. Thus, exactly one of the 
residues has the value 1. Therefore, there is some integer in Z, that, when multiplied 
by w, yields the residue 1. That integer is the multiplicative inverse of w, designated 
w |. Therefore, Z p isin fact a finite field. Furthermore, Equation (4.5) is consistent with 
the existence of a multiplicative inverse and can be rewritten without the condition: 


if (a X b) = (a X c)(mod p) then b = c (mod p) (4.9) 
Multiplying both sides of Equation (4.9) by the multiplicative inverse of a, we have 
((a_') X a X b) = ((a“!) X a X c) (mod p) 
b = c(mod p) 


TAs stated in the discussion of Equation (4.5), two integers are relatively prime if their only common 
positive integer factor is 1. 
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The simplest finite field is GF(2). Its arithmetic operations are easily summarized: 


ar ||@ il |, Oil 
0;0 1 0;0 O 
ili @ i |@ i 


Addition Multiplication Inverses 


In this case, addition is equivalent to the exclusive-OR (XOR) operation, and 
multiplication is equivalent to the logical AND operation. 


Table 4.5 shows arithmetic operations in GF(7). This is a field of order 7 using 
modular arithmetic modulo 7. As can be seen, it satisfies all of the properties 
required of a field (Figure 4.2). Compare this table with Table 4.2. In the latter 
case, we see that the set Zs, using modular arithmetic modulo 8, is not a field. Later 
in this chapter, we show how to define addition and multiplication operations on 
Zg in such a way as to form a finite field. 


Finding the Multiplicative Inverse in GF(p) 


It is easy to find the multiplicative inverse of an element in GF(p) for small values of 
p. You simply construct a multiplication table, such as shown in Table 4.5b, and the 
desired result can be read directly. However, for large values of p, this approach is 
not practical. 


Table 4.5 Arithmetic in GF(7) 


+ 0 it 2 s) 4 5 6 

0 0 al 2 3 4 5 6 

1 1 2 3 4 5 6 0 

2 2 3 4 5 6 0 1 

3 3 4 5 6 0 1 2 

5 

6 6 0 1 2 3 4 5 

(a) Addition modulo 7 
w —-w wl 

x 0 1 2 3 4 2) 6 0 
0 0 0 0 0 0 0 0 1 
1 0 iL 2 3 4 5 6 2 
2 0 2 4 6 il 3 > 3 
3 0 3 6 2 5 il 4 4 
4 0 4 il 5 2 6 3 5 
> 0 5 3 i 6 4 2 6 
6 0 6 4 2 1 


(c) Additive and multiplicative 
(b) Multiplication modulo 7 inverses modulo 7 
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If a and 5 are relatively prime, then b has a multiplicative inverse modulo a. That 
is, if ged(a, b) = 1, then b has a multiplicative inverse modulo a. That is, for positive 
integer b < a, there existsab~' < asuch that bb-' = 1 mod a. If ais a prime number 
and b < a, then clearly a and 5 are relatively prime and have a greatest common 
divisor of 1. We now show that we can easily compute b~! using the extended 
Euclidean algorithm. 

We repeat here Equation (4.7), which we showed can be solved with the 
extended Euclidean algorithm: 


ax + by = d = gced(a, b) 


Now, if gcd(a, b) = 1, then we have ax + by = 1. Using the basic equalities of mod- 
ular arithmetic, defined in Section 4.3, we can say 


[(ax mod a) + (by mod a)] moda = 1 moda 
0 + (by mod a) = 1 


But if by mod a = 1, then y = b~!. Thus, applying the extended Euclidean 
algorithm to Equation (4.7) yields the value of the multiplicative inverse of b if 
gcd(a, b) = 1. Consider the example that was shown in Table 4.4. Here we have 
a = 1759, which is a prime number, and b = 550. The solution of the equation 
1759x + 550y = dyields a value of y = 355.Thus, b~! = 355.To verify, we calculate 
550 x 355 mod 1759 = 195250 mod 1759 = 1. 

More generally, the extended Euclidean algorithm can be used to find a multi- 
plicative inverse in Z,, for any n. If we apply the extended Euclidean algorithm to 
the equation nx + by = d,and the algorithm yields d = 1, then y = b”! in Z,, 


Summary 


In this section, we have shown how to construct a finite field of order p, where p is 
prime. Specifically, we defined GF(p) with the following properties. 


1. GF(p) consists of p elements. 


2. The binary operations + and x are defined over the set. The operations of addi- 
tion, subtraction, multiplication, and division can be performed without leav- 
ing the set. Each element of the set other than 0 has a multiplicative inverse. 


We have shown that the elements of GF(p) are the integers {0,1, ...,p — 1} 
and that the arithmetic operations are addition and multiplication mod p. 


4.6 POLYNOMIAL ARITHMETIC 


Before continuing our discussion of finite fields, we need to introduce the interest- 
ing subject of polynomial arithmetic. We are concerned with polynomials in a single 
variable x, and we can distinguish three classes of polynomial arithmetic. 


e Ordinary polynomial arithmetic, using the basic rules of algebra. 


e Polynomial arithmetic in which the arithmetic on the coefficients is performed 
modulo p ; that is, the coefficients are in GF(p). 
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e Polynomial arithmetic in which the coefficients are in GF(p), and the polynomials 
are defined modulo a polynomial m(x) whose highest power is some integer n. 


This section examines the first two classes, and the next section covers the 
last class. 


Ordinary Polynomial Arithmetic 


A polynomial of degree n (integer n = 0) is an expression of the form 


n 
AX) = yx" + dg x" | +++ + ax + ay = Sax! 
i=0 
where the a; are elements of some designated set of numbers S, called the 
coefficient set, and a, # 0. We say that such polynomials are defined over the 
coefficient set S. 

A zero-degree polynomial is called a constant polynomial and is simply an 
element of the set of coefficients. An nth-degree polynomial is said to be a monic 
polynomial if a,, = 1. 

In the context of abstract algebra, we are usually not interested in evaluating a 
polynomial for a particular value of x [e.g., f(7)]. To emphasize this point, the variable 
x is sometimes referred to as the indeterminate. 

Polynomial arithmetic includes the operations of addition, subtraction, and 
multiplication. These operations are defined in a natural way as though the variable x 
was an element of S. Division is similarly defined, but requires that S be a field. 
Examples of fields include the real numbers, rational numbers, and Z,, for p prime. 
Note that the set of all integers is not a field and does not support polynomial division. 

Addition and subtraction are performed by adding or subtracting corresponding 
coefficients. Thus, if 


m 


fe) = Sax’; g(x) = S1b;x'; n=m 
i=0 i=0 


then addition is defined as 


f(x) + g(x) = > (ai +b) + Pt 


and multiplication is defined as 


n+m ; 
i@) Xea) = Sox 
i=0 
where 
Ch = agby + ayby_4 Se eee ap 1b, + axbo 


In the last formula, we treat a; as zero for i > n and b; as zero for i > m. Note that 
the degree of the product is equal to the sum of the degrees of the two polynomials. 
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As an example, let f(x) = x° + x° + 2 and g(x) = x? — x + 1, where S is the set 
of integers. Then 


fix) + g(x) = + 2x? —x +3 
f(x) — g(x) =e +x4+1 


f(x) X g(x) =x + 3x7 - 2x +2 


Figures 4.3a through 4.3c show the manual calculations. We comment on division 
subsequently. 


Polynomial Arithmetic with Coefficients in Z, 


Let us now consider polynomials in which the coefficients are elements of some 
field F; we refer to this as a polynomial over the field F. In that case, it is easy to 
show that the set of such polynomials is a ring, referred to as a polynomial ring. 
That is, if we consider each distinct polynomial to be an element of the set, then 
that set is a ring.® 

When polynomial arithmetic is performed on polynomials over a field, then 
division is possible. Note that this does not mean that exact division is possible. Let 
us clarify this distinction. Within a field, given two elements a and 5, the quotient 
a/bis also an element of the field. However, given a ring R that is not a field, in 


+x? +2 x + x7 +2 
+ (?-x +41) - (x*-x+1) 
x +2x7— x + 3 x +x4+1 

(a) Addition (b) Subtraction 


+x +2x? 


x +3x2— 2x + 2 xv 


(c) Multiplication (d) Division 
Figure 4.3 Examples of Polynomial Arithmetic 


8In fact, the set of polynomials whose coefficients are elements of a commutative ring forms a polynomial 
ring, but that is of no interest in the present context. 
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general, division will result in both a quotient and a remainder; this is not exact 
division. 


Consider the division 5/3 within a set S. If S is the set of rational numbers, 
which is a field, then the result is simply expressed as 5/3 and is an element 
of S. Now suppose that S is the field Z7. In this case, we calculate (using 
Table 4.5c) 


5/3t (003 mode (5 545) mod 74 


which is an exact solution. Finally, suppose that S is the set of integers, which 
is a ring but not a field. Then 5/3 produces a quotient of 1 and a remainder 
of 2: 


os = il se 2B} 
= il sare 


Thus, division is not exact over the set of integers. 


Now, if we attempt to perform polynomial division over a coefficient set that is 
not a field, we find that division is not always defined. 


If the coefficient set is the integers, then (5x”)/(3x) does not have a solution, 
because it would require a coefficient with a value of 5/3, which is not in the coef- 


ficient set. Suppose that we perform the same polynomial division over Z7. Then 
we have (5x”)/(3x) = 4x, which is a valid polynomial over Z,. 


However, as we demonstrate presently, even if the coefficient set is a field, poly- 
nomial division is not necessarily exact. In general, division will produce a quotient and 
a remainder. We can restate the division algorithm of Equation (4.1) for polynomials 
over a field as follows. Given polynomials f(x) of degree n and g(x) of degree (m), 
(n = m), if we divide f(x) by g(x), we get a quotient g(x) and a remainder r(x) that 
obey the relationship 


fx) = a@x)g(x) + rx) (4.10) 
with polynomial degrees: 


Degree f(x) =n 
Degree g(x) = m 
Degree g(x) =n —m 
Degree r(x) = m-1 


With the understanding that remainders are allowed, we can say that polynomial 
division is possible if the coefficient set is a field. 

In an analogy to integer arithmetic, we can write f(x) mod g(x) for the remain- 
der r(x) in Equation (4.10). That is, r(x) = f(x) mod g(x). If there is no remainder 
[i.e., r(x) = 0], then we can say g(x) divides f(x), written as g(x) | f(x). Equivalently, 
we can say that g(x) is a factor of f(x) or g(x) is a divisor of f(x). 
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For the preceding example [f(x) = x° + x? + 2andg(x) = x? — x + 1], fx)/e(x) 
produces a quotient of q(x) = x + 2 and a remainder r(x) = x, as shown in 
Figure 4.3d. This is easily verified by noting that 


q(x)g(x) + r(x) = (x +2)? -—x4+1 +x= (4x? -x4+2)4+% 
=x +4 +2 = fx) 


For our purposes, polynomials over GF(2) are of most interest. Recall 
from Section 4.5 that in GF(2), addition is equivalent to the XOR operation, and multi- 
plication is equivalent to the logical AND operation. Further, addition and subtraction 
are equivalent mod 2:1 +1=1-1=0;1+0=1-0=1;0+1=0-1=1. 


Figure 4.4 shows an example of polynomial arithmetic over GF(2). For 
f(x) = (x7 + xP + x4 4+ 3 + x + 1) and g(x) = (x° + x + 1), the figure shows 


fx) + g(x); fl) — g(x); fl) X g(x); and f(x)/g(x). Note that g(x) |f(). 


A polynomial f(x) over a field F is called irreducible if and only if f(x) cannot 
be expressed as a product of two polynomials, both over F, and both of degree lower 
than that of f(x). By analogy to integers, an irreducible polynomial is also called a 
prime polynomial. 


The polynomial? f(x) = x* + 1 over GF(2) is reducible, because 
xt+1 s(x 414+ xr4+2x4+1). 


Consider the polynomial f(x) = x° + x + 1.It is clear by inspection that x is not 
a factor of f(x). We easily show that x + 1 is not a factor of f(x): 


we+x 


xt+1/3 ar dear Il 
e+ x7 
xr+x 
+x 


1 


Thus, f(x) has no factors of degree 1. But it is clear by inspection that if f(x) is 
reducible, it must have one factor of degree 2 and one factor of degree 1. 
Therefore, f(x) is irreducible. 


°Tn the remainder of this chapter, unless otherwise noted, all examples are of polynomials over GF(2). 
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x7 +x ¢x44+33 +x4+1 
+(x? +x+1) 
x! +x> + x4 
(a) Addition 
x! +x +¢x44+33 +x4+1 
= (x3 +x+1) 
x! +x 4x4 


(b) Subtraction 


wal Hee tas tx +x4+1 
x (x3 +x +1) 
a! 4x ¢x44x3 db 5p 46 il 
x8 +x9+x°> +44 4x7 +x 
ee oc! oe xc® re > 
x10 fog +x? +1 
(c) Multiplication 
x44 1 
Xe eed / x! txr¢xt4+x° 5p te Tl 
x! $x> + x4 
x +x+1 
x +x+1 


(d) Division 


Figure 4.4 Examples of Polynomial Arithmetic over GF(2) 


Finding the Greatest Common Divisor 


We can extend the analogy between polynomial arithmetic over a field and integer 
arithmetic by defining the greatest common divisor as follows. The polynomial c(x) 
is said to be the greatest common divisor of a(x) and b(x) if the following are true. 


1. c(x) divides both a(x) and b(x). 
2. Any divisor of a(x) and b(x) is a divisor of c(x). 
An equivalent definition is the following: gcd[a(x), b(x)] is the polynomial of 
maximum degree that divides both a(x) and b(x). 
We can adapt the Euclidean algorithm to compute the greatest common divi- 


sor of two polynomials. The equality in Equation (4.6) can be rewritten as the fol- 
lowing theorem. 


128 CHAPTER 4 / BASIC CONCEPTS IN NUMBER THEORY AND FINITE FIELDS 
gcd[a(x), b(x)] = ged[b(x), a(x) mod b(x)] (4.11) 


Equation (4.11) can be used repetitively to determine the greatest common 
divisor. Compare the following scheme to the definition of the Euclidean algorithm 
for integers. 


Euclidean Algorithm for Polynomials 


Calculate Which satisfies 
r(x) = a(x)mod b(x) a(x) = qy(x)b(x) + n@) 
r(x) = b(x)mod r)(x) D(x) = golx)ri(x) + r(x) 
r(x) = r(x)mod r(x) r(x) = q3(x)ro(x) + 13(x) 


r(x) = Ty—-2(x) mod Ty-1(x) Tn-2(X) = An(X)n—1) + r,(x) 
Tn—-1(x) 7 An+ (4) Mn(X) +0 


Tn+1(x) = Tn—1(x) mod r(x) =0 d(x) = gcd(a(x), b(x)) = 1)(X) 


At each iteration, we have d(x) = ged(r;+,(x), r(x)) until finally d(x) = 
gcd(r,,(x), 0) = r,(x). Thus, we can find the greatest common divisor of two integers 
by repetitive application of the division algorithm. This is the Euclidean algorithm 
for polynomials. The algorithm assumes that the degree of a(x) is greater than the 
degree of b(x). 


Find gcd[a(x),b(x)] for a(x) = x° +P + x44 24+ 2x7 +x41 and D(x) = 
xt + x? + x + 1. First, we divide a(x) by b(x): 
er+x 
xt+ xP t¢xti/x6+r¢axtt Pt rPtrxtl 
+ x44 3 + x? 
x ap de ap Il 
a +x4+xr4+x 
e+ x ar Il 
This yields r;(x) = x° + x? + 1 and q(x) =x7+x. 


Then, we divide b(x) by r(x). 


we ae Il 
+x + if +x +¢x+1 
x +x ar 3 
xe + x? ar il 
xe + x? ae il 


This yields r(x) = 0 and qo(x) = x + 1. 
Therefore, gcd[a(x), b(x)] = n(x) = xe +x? +1. 
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Summary 


We began this section with a discussion of arithmetic with ordinary polynomials. In 
ordinary polynomial arithmetic, the variable is not evaluated; that is, we do not plug 
a value in for the variable of the polynomials. Instead, arithmetic operations are per- 
formed on polynomials (addition, subtraction, multiplication, division) using the 
ordinary rules of algebra. Polynomial division is not allowed unless the coefficients 
are elements of a field. 

Next, we discussed polynomial arithmetic in which the coefficients are elements 
of GF(p). In this case, polynomial addition, subtraction, multiplication, and division 
are allowed. However, division is not exact; that is, in general division results in a 
quotient and a remainder. 

Finally, we showed that the Euclidean algorithm can be extended to find the 
greatest common divisor of two polynomials whose coefficients are elements of a field. 

All of the material in this section provides a foundation for the following section, 
in which polynomials are used to define finite fields of order p”. 


4.7 FINITE FIELDS OF THE FORM GE(2") 


Earlier in this chapter, we mentioned that the order of a finite field must be of the 
form p”, where p is a prime and n is a positive integer. In Section 4.5, we looked at 
the special case of finite fields with order p. We found that, using modular arith- 
metic in Z,, all of the axioms for a field (Figure 4.2) are satisfied. For polynomials 
over p”, with n > 1, operations modulo p” do not produce a field. In this section, 
we show what structure satisfies the axioms for a field in a set with p” elements and 
concentrate on GF(2”). 


Motivation 


Virtually all encryption algorithms, both symmetric and public key, involve arith- 
metic operations on integers. If one of the operations that is used in the algorithm 
is division, then we need to work in arithmetic defined over a field. For conve- 
nience and for implementation efficiency, we would also like to work with inte- 
gers that fit exactly into a given number of bits with no wasted bit patterns. That 
is, we wish to work with integers in the range 0 through 2” — 1, which fit into an 
n-bit word. 


Suppose we wish to define a conventional encryption algorithm that operates on 
data 8 bits at a time, and we wish to perform division. With 8 bits, we can represent 
integers in the range 0 through 255. However, 256 is not a prime number, so that if 
arithmetic is performed in Z>s5¢ (arithmetic modulo 256), this set of integers will 


not be a field. The closest prime number less than 256 is 251. Thus, the set Zo5,, 
using arithmetic modulo 251, is a field. However, in this case the 8-bit patterns 
representing the integers 251 through 255 would not be used, resulting in 
inefficient use of storage. 
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As the preceding example points out, if all arithmetic operations are to be 
used and we wish to represent a full range of integers in n bits, then arithmetic 
modulo 2” will not work. Equivalently, the set of integers modulo 2” for n > 1, is 
not a field. Furthermore, even if the encryption algorithm uses only addition and 
multiplication, but not division, the use of the set Z> is questionable, as the follow- 
ing example illustrates. 


Suppose we wish to use 3-bit blocks in our encryption algorithm and use only the 
operations of addition and multiplication. Then arithmetic modulo 8 is well 
defined, as shown in Table 4.2. However, note that in the multiplication table, the 
nonzero integers do not appear an equal number of times. For example, there are 
only four occurrences of 3, but twelve occurrences of 4. On the other hand, as 
was mentioned, there are finite fields of the form GF(2”), so there is in particular 
a finite field of order 27 =8. Arithmetic for this field is shown in Table 4.6. In this 
case, the number of occurrences of the nonzero integers is uniform for 
multiplication. To summarize, 


Integer 


i 2 3 
Occurrences in Zg AL fal 
Occurrences in GF(2*) 7 7 7 


For the moment, let us set aside the question of how the matrices of Table 4.6 
were constructed and instead make some observations. 


. The addition and multiplication tables are symmetric about the main 
diagonal, in conformance to the commutative property of addition and 
multiplication. This property is also exhibited in Table 4.2, which uses 
mod 8 arithmetic. 


. All the nonzero elements defined by Table 4.6 have a multiplicative inverse, 
unlike the case with Table 4.2. 

. The scheme defined by Table 4.6 satisfies all the requirements for a finite 
field. Thus, we can refer to this scheme as GF(2°). 


. For convenience, we show the 3-bit assignment used for each of the ele- 
ments of GF(2°). 


Intuitively, it would seem that an algorithm that maps the integers unevenly 
onto themselves might be cryptographically weaker than one that provides a uniform 
mapping. Thus, the finite fields of the form GF(2”) are attractive for cryptographic 
algorithms. 

To summarize, we are looking for a set consisting of 2” elements, together with 
a definition of addition and multiplication over the set that define a field. We can 
assign a unique integer in the range 0 through 2” — 1 to each element of the set. 
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Table 4.6 Arithmetic in GF(2°) 


000 
001 
010 
O11 
100 
101 
110 
111 


000 
001 
010 
O11 
100 
101 
110 
111 


000 O01 O10 O11 100 101 110 111 
+ 0 1 2 3 4 5 6 7 
0 0 1 2 3 4 5 6 7 
1 1 0 3 a 5 4 7 6 
2 3 0 1 6 7 4 5 
3 2 1 0 7 6 5 4 
4 5 6 7 0 1 2 3 
5 4 7 6 1 0 3 2 
6 7 4 5 2 3 0 1 
7 6 5 4 3 2 1 0 
(a) Addition 
000 001 010 O11 100 101 110+ 111 oe ap wo 
x 0 1 2 3 4 5 6 7 7 
0 0 0 0 0 0 0 0 0 ; 
1 0 1 2 3 4 5 6 7 
2 0 2 4 6 3 1 7 5 = 
3 0 3 6 5 7 4 1 2 ? 
4] 0 4 3 7 6 2 5 1 4 
5 0 5 1 4 2 7 3 6 5 
6 0 6 7 it 5 3 2 4 6 
7 0 7 5 2 1 6 4 3 


(b) Multiplication (c) Additive and multiplicative 
inverses 


Keep in mind that we will not use modular arithmetic, as we have seen that this does 
not result in a field. Instead, we will show how polynomial arithmetic provides a 
means for constructing the desired field. 


Modular Polynomial Arithmetic 


Consider the set S of all polynomials of degree n — 1 or less over the field Z,,. Thus, 
each polynomial has the form 


nol 
f() = Ay yx™ | + Ayigx”? +o + yx + ay = Sax 
i=0 


where each a; takes on a value in the set {0,1, ..., p — 1}. There are a total of p” 
different polynomials in S. 
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ag Dye 
xe ar il Dse ap Al 
2 xe ap 2 De ap 2 


For p = 2 andn = 3, the 2? = 8 polynomials in the set are 


xe ar I e+x 
5? ese El 
x +1 


With the appropriate definition of arithmetic operations, each such set S is a 


finite field. The definition consists of the following elements. 


1. Arithmetic follows the ordinary rules of polynomial arithmetic using the basic 


rules of algebra, with the following two refinements. 


arithmetic for the finite field vie 


Arithmetic on the coefficients is performed modulo p. That is, we use the rules of 


3. If multiplication results in a polynomial of degree greater than n — 1, then the 


polynomial is reduced modulo some irreducible polynomial m(x) of degree n. 
That is, we divide by m(x) and keep the remainder. For a polynomial f(x), the 


remainder is expressed as r(x) = f(x) mod m(x). 


The Advanced Encryption Standard (AES) uses arithmetic in the finite field GF(2°), 
with the irreducible polynomial m(x) = x® + x* + x° + x + 1. Consider the two polyno- 


mials f(x) = x° + xt + x7 + x + Land g(x) = x’ + x + 1.Then 
fix) + g(x) = x txt te +xt+1tx txt 
= x) + x84 x44 x 
fix) X g(x) = xB txt gt xP +84 x7 
+x74+ P4047 4x 
+x©+x4+ x? t+x4+1 


H=xB txt 4 y+ 84+ x8 + MP txt t¢ Pt] 


r +x 


BH xtt ext 1/84 x4 24 x84 a7 ¢ x9 ¢ O44 4 841 


xb +x? +38 Be ee 


ae Saye hye 
ae + x/ + x° a 


x’ +x® 


Therefore, f(x) X g(x) mod m(x) = x7 + x® + 1. 


a Il 
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As with ordinary modular arithmetic, we have the notion of a set of residues in 
modular polynomial arithmetic. The set of residues modulo m(x), an nth-degree 
polynomial, consists of p” elements. Each of these elements is represented by one of 
the p” polynomials of degree m <n. 


The residue class [x + 1], (modm(x)), consists of all polynomials a(x) such that 


a(x) = (x + 1) (modm(x)). Equivalently, the residue class [x + 1] consists of all 
polynomials a(x) that satisfy the equality a(x)modm(x) = x + 1. 


It can be shown that the set of all polynomials modulo an irreducible nth-degree 
polynomial (x) satisfies the axioms in Figure 4.2, and thus forms a finite field. 
Furthermore, all finite fields of a given order are isomorphic; that is, any two finite- 
field structures of a given order have the same structure, but the representation or 
labels of the elements may be different. 


To construct the finite field GF(2*), we need to choose an irreducible polynomial 
of degree 3. There are only two such polynomials: («7 + x7 + 1) and 
(x3 + x + 1). Using the latter, Table 4.7 shows the addition and multiplication 
tables for GF(23). Note that this set of tables has the identical structure to 
those of Table 4.6. Thus, we have succeeded in finding a way to define a field of 
order 2°. 


We can now read additions and multiplications from the table easily. For exam- 
ple, consider binary 100 + 010 = 110. This is equivalent to x* + x. Also consider 
100 x 010 = 011, which is equivalent to x” x x = x* and reduces to x + 1. 


Finding the Multiplicative Inverse 


Just as the Euclidean algorithm can be adapted to find the greatest common divisor 
of two polynomials, the extended Euclidean algorithm can be adapted to find the 
multiplicative inverse of a polynomial. Specifically, the algorithm will find the multi- 
plicative inverse of b(x) modulo a(x) if the degree of b(x) is less than the degree of 
a(x) and gcd[a(x), b(x)] = 1. If a(x) is an irreducible polynomial, then it has no 
factor other than itself or 1,so that gcd[a(x), b(x)] = 1.The algorithm can be charac- 
terized in the same way as we did for the extended Euclidean algorithm for integers. 
Given polynomials a(x) and b(x) with the degree of a(x) greater than the degree of 
b(x), we wish to solve the following equation for the values v(x), w(x), and d(x), where 
d(x) = ged[a(x), b(x)]: 
a(x)v(x) + b(x)w(x) = d(x) 


If d(x) = 1, then w(x) is the multiplicative inverse of b(x) modulo a(x). The calculations 
are as follows. 


vel 


Table 4.7 Polynomial Arithmetic Modulo (x7 + x + 1) 


000 
001 
010 
O11 
100 
101 
110 
111 


000 001 010 O11 100 101 110 111 


000 
001 
010 
O11 
100 
101 
110 
111 


0 
0 
0 
0 
0 
0 
0 
0 


(b) Multiplication 
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Extended Euclidean Algorithm for Polynomials 
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Calculate 


Which satisfies 


Calculate 


Which satisfies 


r_s(x) = a(x) 


v_1(x) = 1; w_,(x) = 0 


a(x) = a(x)v_y(x) + 
bw_(x) 


ro(x) = b(x) 


Vo(x) = 0; wo(x) = 1 


b(x) = a(x)vo(x) + 
b(x)wo(x) 


r(x) = a(x) mod b(x) 
qi(x) = quotient of 
a(x)/b(x) 


a(x) = qy(x)b(x) + 
r(x) 


v(x) = v-1(x) — 
qi(x)vo(x) = 1 

w(x) = w(x) — 
qi(x)wo(x) = —qir) 


r(x) = a(x)vi(x) + 
b(x)w (x) 


r(x) = b(x) mod r;(x) 
qx(x) = quotient of 
b(x)/r,(x) 


r3(x) = r(x) mod r(x) 
q3(x) = quotient of 
r(x)/ro(x) 


b(x) = qo(x)ri(x) + 
r(x) 


r(x) = q3(x)ra(x) + 
13(x) 


v(x) = vo(x) — 
qa(x)v1 (x) 
W(x) = Wo(x) — 
qa(x)w (x) 
v3(x) = v(x) — 
q3(x)v2(x) 
w3(x) = wi(x) — 
q3(x)wa(x) 


r(x) = a(x)vo(x) + 
b(x)w2(x) 


r3(x) = a(x)v3(x) + 
b(x)w3(x) 


r(x) = Tn-2(X) mod 
Tn-1(X) 

n(x) = quotient of 
Tn —-2(X)/Py—3(%) 


Tn—2(X) ee. AnlX)Tn—1(X) 
+ r,(x) 


Va(X) = Vn-2(x) — 
In(X)Vn-1) 
W(X) = Wy—2(x) — 
In(X)Wn—1) 


M(x) = a(x)vp(x) + 
D(x)wy(x) 


Tn41(X) = Ty—1(x) mod 
r(x) = 0 
Qn+i(X) = quotient of 


1 n—1(0)/Py 2X) 


Tn—1(X) = Gn+1(X)in(X) 
+ 0 


d(x) = ged(a(x), 
b(x)) = r,(x) 

v(2e) = vy (2); w(x) = 
W(X) 


Table 4.8 shows the calculation of the multiplicative inverse of (x’ + x + 1) 
mod (x° + x4 + x3 + x + 1). The result is that (x’ + x + 1)7! = (x’). That is, 
(x7 + x + 1)(x’) = 1( mod (x8 + x4 + x3 + x + 1)). 


Computational Considerations 


A polynomial f(x) in GF(2”) 


f(x) = Ay — 1X") + Ay—oX* + 


n-1 


+ ax + ay = Sax! 


i=0 


can be uniquely represented by the sequence of its n binary coefficients (a,_1, 4-2, 
..., 9). Thus, every polynomial in GF(2”) can be represented by an n-bit number. 
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Tables 4.6 and 4.7 show the addition and multiplication tables for GF(2°) modulo 


m(x) = (x* + x + 1). Table 4.6 uses the binary representation, and Table 4.7 uses 
the polynomial representation. 


AppiTIon We have seen that addition of polynomials is performed by adding 
corresponding coefficients, and, in the case of polynomials over Z5, addition is just the 
XOR operation. So, addition of two polynomials in GF(2”) corresponds to a bitwise 
XOR operation. 


Consider the two polynomials in GF(2°) from our earlier example: 
f(x) = x8 + x4 4% +e 4+ Land g(x) =x7 + x41. 
(x® + x4 1) + (x? +x 41) =x! + x© + x4 + x (polynomial notation) 
(01010111) @ (10000011) = (11010100) (binary notation) 
{57} @ {83} = {D4} (hexadecimal notation)!” 


Mu.tTiPLicATION There is no simple XOR operation that will accomplish 
multiplication in GF(2”). However, a reasonably straightforward, easily implemented 
technique is available. We will discuss the technique with reference to GF(2°) using 
m(x) = x8 + x4 + x° + x + 1, which is the finite field used in AES. The technique 
readily generalizes to GF(2”). 

The technique is based on the observation that 


x8 mod m(x) = [m(x) — x8] = G4 + x8 +x +41) (4.12) 


1] 


Initialization | a(x) = x8 + x + 1; v_4(x) = 1; w_,(x) = 0 
b(x) = x! 1; vo(x) = 0; wo(x) = 1 

Iteration 1 a(x) = x; n(x) 34 y7 41 
v(x) = 1; wi(x) = x 


Iteration 2 aoe) = 36 1; r(x) = x 


V2(x) : 1; w(x) = xt +x +x41 


Iteration 3 q3(x) - 2 + x; 13(x) = 1 
va(x) = x? + x? + x +15 w(x) = x 


Iteration 4 qa(x) = x; r4(x) = 0 
va(x) = x7 + x + 1; wa(x) 
Result d(x) = r3(x) = ged(a(x), b(x)) = 1 
w(x) = w(x) = (x! 4 1)! mod (x° 


104 basic refresher on number systems (decimal, binary, hexadecimal) can be found at the Computer 
Science Student Resource Site at WilliamStallings.com/StudentSupport.html. Here each of two groups 
of 4 bits in a byte is denoted by a single hexadecimal character, and the two characters are enclosed in 
brackets. 
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A moment’s thought should convince you that Equation (4.12) is true; if you 
are not sure, divide it out. In general, in GF(2”) with an nth-degree polynomial p(x), 
we have x” mod p(x) = [p(x) — x"]. 

Now, consider a polynomial in GF(2), which has the form f(x) = b7x’ + bex® + 
bsx> + byx*t + 3x3 + box? + b x + bo. If we multiply by x, we have 


x X fix) = (box® + box? + bsx® + by? + byxt 
+ box? + byx? + box) mod m(x) (4.13) 


If b; = 0, then the result is a polynomial of degree less than 8, which is already 
in reduced form, and no further computation is necessary. If b7 = 1, then reduction 
modulo m(x) is achieved using Equation (4.12): 


x X f(x) = (box! + bsx® + bax? + baxt + box? + byx? + box) 
+ (t+ 24x41) 


It follows that multiplication by x (i.e., 00000010) can be implemented as a 1-bit left 
shift followed by a conditional bitwise XOR with (00011011), which represents 
(xt + x° + x + 1).To summarize, 


(b6bsb4b3b2bb,0) if bz = 


4.14 


x X fix) = { 
Multiplication by a higher power of x can be achieved by repeated application 


of Equation (4.14). By adding intermediate results, multiplication by any constant in 
GF(2°) can be achieved. 


In an earlier example, we showed that for f(x) = x° + x4 + x? + x + 1, g(x) = x7 + 

x + 1,and m(x) = x8 + x* + x + x + 1,we have f(x) X g(x) mod m(x) = x’ + x° + 1. 
Redoing this in binary arithmetic, we need to compute (01010111) x (10000011). First, we 
determine the results of multiplication by powers of x: 


So, 


(01010111) x (00000010) = (10101110) 
(01010111) x (00000100) = (01011100) @ (00011011) = (01000111) 
(01010111) x (00001000) = (10001110) 
(01010111) x (00010000) = (00011100) @ (00011011) = (00000111) 
(01010111) x (00100000) = (00001110) 
(01010111) x (01000000) = (00011100) 
(01010111) x (10000000) = (00111000) 


(01010111) x (10000011) = (01010111) x [(00000001) @ (00000010) @ (10000000)] 


= (01010111) @ (10101110) @ (00111000) = (11000001) 


which is equivalent to x’ + x° + 1. 
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Using a Generator 


An equivalent technique for defining a finite field of the form GF(2”), using the 
same irreducible polynomial, is sometimes more convenient. To begin, we need two 
definitions: A generator g of a finite field F of order q (contains q elements) is an 
element whose first g — 1 powers generate all the nonzero elements of F. That is, 
the elements of F consist of 0, ge" g', waaeiee Consider a field F defined by a 
polynomial f(x). An element b contained in F is called a root of the polynomial if 
f(b) = 0. Finally, it can be shown that a root g of an irreducible polynomial is a 
generator of the finite field defined on that polynomial. 


Let us consider the finite field GF(2*), defined over the irreducible polynomial 
x3 +x+1, discussed previously. Thus, the generator g must satisfy 
f(g) = g + ¢ + 1 = 0. Keep in mind, as discussed previously, that we need not 
find a numerical solution to this equality. Rather, we deal with polynomial arith- 
metic in which arithmetic on the coefficients is performed modulo 2. Therefore, 
the solution to the preceding equality is g’ = —g — 1 = g + 1. We now show 
that g in fact generates all of the polynomials of degree less than 3. We have the 
following. 


S=eev=ag+D=ae+e 
gs=es)=eetg=agte=agtgti 
S=e@Pr=aaetgthagtytgaetgtgtl=agtl 
gs=ee)=9etlh=agtg=gtgtl=l=2° 


We see that the powers of g generate all the nonzero polynomials in GF(2°). 
Also, it should be clear that g* = g*™°47 for any integer k. Table 4.9 shows the 
power representation, as well as the polynomial and binary representations. 


(Continued) 


Table 4.9 Generator for GF(23) using x? + x + 1 


Power Polynomial Binary Decimal (Hex) 
Representation Representation Representation Representation 


0 000 0 


g(= 8’) 001 


010 


100 


il 
2 
4 
3 
6 
7 
5 
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(Continued) 

This power representation makes multiplication easy. To multiply in the 
power notation, add exponents modulo 7. For example, g* + g° = g@0mod”) = 
g = g + 1.The same result is achieved using polynomial arithmetic: We have 
gi =’ +g and go = 9’ +1. Then, ( +g)X(P+1l=H=e¢tP4+ePH1. 
Next, we need to determine (g* + g* + g* + 1) mod(g* + g + 1) by division: 


@ sp il 
gtgti/ft gi gts 
gaa gig 
g 
gt Bap il 
wa il 


We get a result of g + 1, which agrees with the result obtained using the power 
representation. 

Table 4.10 shows the addition and multiplication tables for GF(2°) using 
the power representation. Note that this yields the identical results to the 
polynomial representation (Table 4.7) with some of the rows and columns 
interchanged. 


In general, for GF(2") with irreducible polynomial f(x), determine 
g” = f(g) — g”. Then calculate all of the powers of g from g”*! through g” 7. The 
elements of the field correspond to the powers of g from g® through g”’ 7 plus the 
value 0. For multiplication of two elements in the field, use the equality 
gk = gkmod?"—)) for any integer k. 


Summary 


In this section, we have shown how to construct a finite field of order 2”. Specifically, 
we defined GF(2”) with the following properties. 


1. GF(2") consists of 2” elements. 


2. The binary operations + and x are defined over the set. The operations of addi- 
tion, subtraction, multiplication, and division can be performed without leav- 
ing the set. Each element of the set other than 0 has a multiplicative inverse. 


We have shown that the elements of GF(2”) can be defined as the set of all 
polynomials of degree n — 1 or less with binary coefficients. Each such polynomial 
can be represented by a unique -bit value. Arithmetic is defined as polynomial 
arithmetic modulo some irreducible polynomial of degree n. We have also seen that 
an equivalent definition of a finite field GF(2”) makes use of a generator and that 
arithmetic is defined using powers of the generator. 


Ort 


Table 4.10 GF(23) Arithmetic Using Generator for the Polynomial (x* + x + 1) 
000 001 010 100 O11 110 1 101 


000 
001 
010 


100 
O11 


110 
111 
101 


o 


Og 


i) 


iss) 


og, 09 og 


an 


Og 99 
Jn 


000 001 010 100 O11 110 111 101 


000 
001 
010 
100 
O11 
110 
111 
101 


me RE oO XK 


i) 


as) 


oe, Og oR 


ta 


o;Jo}]ol]o;o;}o;o;o] co 


Gq 99 
eS 


(b) Multiplication 
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Key Terms 


abelian group commutative divisor 


associative commutative ring Euclidean algorithm 
coefficient set cyclic group field 
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finite field 
finite group 
finite ring 
generator 


greatest common divisor 


group 


infinite ring 

integral domain 

inverse element 

irreducible polynomial 
modular arithmetic 

modular polynomial arithmetic 


order 

polynomial 
polynomial arithmetic 
polynomial ring 
prime number 

prime polynomial 


identity element 
infinite field 
infinite group 


modulo operator relatively prime 
modulus residue 
monic polynomial ring 


Review Questions 


4.1 Briefly define a group. 

4.2 Briefly define a ring. 

4.3 Briefly define a field. 

4.4 What does it mean to say that b is a divisor of a? 

4.5 What is the difference between modular arithmetic and ordinary arithmetic? 
4.6 List three classes of polynomial arithmetic. 


Problems 


4.1 For the group S,, of all permutations of n distinct symbols, 
a. what is the number of elements in S,,? 
b. show that S,, is not abelian for n > 2. 
4.2. Does the set of residue classes (mod3) form a group 
a. with respect to modular addition? 
b. with respect to modular multiplication? 


4.3 Consider the set § = {a, b} with addition and multiplication defined by the following 


tables. 
a b x a b 
a a b a a a 
b b a b a b 


Is S a ring? Justify your answer. 

4.4 Reformulate Equation (4.1), removing the restriction that a is a nonnegative integer. 
That is, let a be any integer. 

4.5 Draw a figure similar to Figure 4.1 for a < 0. 

4.6 For each of the following equations, find an integer x that satisfies the equation. 
a. 5x = 4(mod 3) 
b. 7x = 6 (mod 5) 
c. 9x = 8 (mod 7) 

4.7 In this text, we assume that the modulus is a positive integer. But the definition of 
the expression a modn also makes perfect sense if n is negative. Determine the 


following: 

a. 5mod3 
b. 5 mod —3 
c. —5 mod 3 


d. —5 mod —3 


4.8 


4.9 


4.10 
4.11 


4.12 


4.13 
4.14 


4.15 


4.16 


4.17 


4.18 
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A modulus of 0 does not fit the definition but is defined by convention as follows: 
amod0 = a. With this definition in mind, what does the following expression mean: 
a = b (mod 0)? 

In Section 4.3, we define the congruence relationship as follows: Two integers a and b 
are said to be congruent modulo n if (a modn) = (b mod zn). We then proved that 
a = b(modn) if n| (a — b). Some texts on number theory use this latter relation- 
ship as the definition of congruence: Two integers a and b are said to be congruent 
modulo n if n | (a — b). Using this latter definition as the starting point, prove that, if 
(amodn) = (b mod n), then n divides (a — b). 

What is the smallest positive integer that has exactly k divisors, for 1 = k = 6? 
Prove the following: 

a. a = b(modn) implies b = a (mod n) 

b. a = b(modn) and b = c (mod n) imply a = c (mod n) 

Prove the following: 

a. [(amodn) — (bmodn)]modn = (a — b) modn 

b. [(amodn) X (bmodn)] modn = (a X b) modu 

Find the multiplicative inverse of each nonzero element in Zs. 


Show that an integer N is congruent modulo 9 to the sum of its decimal digits. For 
example, 475 =4+7+5=16=1+6#=7 (mod9). This is the basis for the 
familiar procedure of “casting out 9’s” when checking computations in arithmetic. 

a. Determine gcd(24140, 16762). 

b. Determine gcd(4655, 12075). 

The purpose of this problem is to set an upper bound on the number of iterations of 
the Euclidean algorithm. 

a. Suppose that m = qn + rwithg > O0and0 = r < n. Show that m/2 > r. 

b. Let A; be the value of A in the Euclidean algorithm after the ith iteration. Show that 


Aisa < a 


c. Show that if m,n, and N are integers with (1 = m,n, = 2), then the Euclidean 
algorithm takes at most 2N steps to find gcd(m, n). 
The Euclidean algorithm has been known for over 2000 years and has always been a 
favorite among number theorists. After these many years, there is now a potential 
competitor, invented by J. Stein in 1961. Stein’s algorithms is as follows. Determine 
gcd(A, B) with A, B = 1. 
STEP 1 Set A; = A,B, = B,C, = 1 
STEP 2 n (1) IfA, = B, stop. gcd(A, B) = A,C, 
(2) If A, and B,, are both even, set A,+, = A,/2, Bn, = B,/2, Cr+) = 2C, 
(3) If A, is even and B,, is odd, set A,+; = A,/2, But) = Bn, Coz1 = Ch 
(4) If A, is odd and B,, is even, set A,+; = Ay, Bya, = By/2, G41 = Ch 
(5) If.A,, and B,, are both odd, set A,.; = |.A,— B,|,Byi; = min (B,, A,), 
C41 > GC, 
Continue to stepn + 1. 
a. To get a feel for the two algorithms, compute gcd(2152, 764) using both the 
Euclidean and Stein’s algorithm. 
b. What is the apparent advantage of Stein’s algorithm over the Euclidean algorithm? 


a. Show that if Stein’s algorithm does not stop before the nth step, then 
Cr+i X gcd(An+1, Basi) = Cr X ged(An, Bn) 

b. Show that if the algorithm does not stop before step (n — 1), then 

AnBn 

ee 


An+2Bn+2 = 
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c. Show that if1 =< A,B = 2%, then Stein’s algorithm takes at most 4N steps to find 
gcd(m, n). Thus, Stein’s algorithm works in roughly the same number of steps as 
the Euclidean algorithm. 

d. Demonstrate that Stein’s algorithm does indeed return ged(A, B). 

4.19 Using the extended Euclidean algorithm, find the multiplicative inverse of 

a. 1234 mod 4321 

b. 24140 mod 40902 

c. 550 mod 1769 

4.20 Develop a set of tables similar to Table 4.5 for GF(5). 

4.21 Demonstrate that the set of polynomials whose coefficients form a field is a ring. 

4.22 Demonstrate whether each of these statements is true or false for polynomials 
over a field. 

a. The product of monic polynomials is monic. 

b. The product of polynomials of degrees m and n has degree m + n. 

c. The sum of polynomials of degrees m and n has degree max [m, n]. 

4.23 For polynomial arithmetic with coefficients in Zi, perform the following 
calculations. 

a. (7x + 2) — (x7 +5) 

b. (6x? + x + 3) X (Sx? + 2) 

4.24 Determine which of the following are reducible over GF(2). 

a xt) 

b. x 4+x741 

c. x4 + 1 (be careful) 

4.25 Determine the gcd of the following pairs of polynomials. 

a. x8 +x + 1andx? + x + 1 over GF(2) 

b. x3 — x + Land x? + 1 over GF(3) 

ce tat to3 — x? — x + Landx? + x? + x + 1 over GF(3) 

d. x° + 88x* + 73x3 + 83x? + Sx + 67 and x + 97x? + 40x + 38 over GF(101) 

4.26 Develop a set of tables similar to Table 4.7 for GF(4) with m(x) = x? + x +1. 
4.27 Determine the multiplicative inverse of x«°+x+1 in GF(2+) with 

mx) =xt+x41. 

4.28 Develop a table similar to Table 4.9 for GF(2*) with m(x) = x4 + x + 1. 


Programming Problems 


4.29 Write a simple four-function calculator in GF(2*). You may use table lookups for the 
multiplicative inverses. 


4.30 Write a simple four-function calculator in GF(2°). You should compute the multi- 
plicative inverses on the fly. 


APPENDIX 4A THE MEANING OF MOD 


The operator mod is used in this book and in the literature in two different ways: as 
a binary operator and as a congruence relation. This appendix explains the distinc- 
tion and precisely defines the notation used in this book regarding parentheses. This 
notation is common but, unfortunately, not universal. 
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The Binary Operator mod 


If ais an integer and n is a nonzero integer, we define a mod v to be the remainder 
when a is divided by n. The integer n is called the modulus, and the remainder is 
called the residue. Thus, for any integer a, we can always write 


a= |a/ln| X n+ (amodn) 
Formally, we define the operator mod as 
amodn=a-—|aln| Xn for n #0 


As a binary operation, mod takes two integer arguments and returns the 
remainder. For example, 7 mod 3 = 1. The arguments may be integers, integer 
variables, or integer variable expressions. For example, all of the following are 
valid, with the obvious meanings: 


7 mod 3 
7modm 
x mod 3 
x modm 
(x? + y + 1) mod (2m + n) 


where all of the variables are integers. In each case, the left-hand term is divided by 
the right-hand term, and the resulting value is the remainder. Note that if either the 
left- or right-hand argument is an expression, the expression is parenthesized. The 
operator mod is not inside parentheses. 

In fact, the mod operation also works if the two arguments are arbitrary real 
numbers, not just integers. In this book, we are concerned only with the integer 
operation. 


The Congruence Relation mod 


As a congruence relation, mod expresses that two arguments have the same 
remainder with respect to a given modulus. For example, 7 = 4 (mod 3) expresses 
the fact that both 7 and 4 have a remainder of 1 when divided by 3. The following 
two expressions are equivalent: 


a = b(mod m) = amodm = bmodm 


Another way of expressing it is to say that the expression a = b (mod m) is the same 
as saying that a — 5 is an integral multiple of m. Again, all the arguments may be 
integers, integer variables, or integer variable expressions. For example, all of the 
following are valid, with the obvious meanings: 

7 = 4(mod 3) 

x = y (mod m) 

(x? + y + 1) = (a + 1) (mod [m + n)) 
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where all of the variables are integers. Two conventions are used. The congruence 
sign is =.The modulus for the relation is defined by placing the mod operator fol- 
lowed by the modulus in parentheses. 

The congruence relation is used to define residue classes. Those numbers that 
have the same remainder r when divided by m form a residue class (mod m). There 
are m residue classes (mod m). For a given remainder r, the residue class to which it 
belongs consists of the numbers 


rrim,r+2m,... 
According to our definition, the congruence 
a = b (mod m) 


signifies that the numbers a and b differ by a multiple of m. Consequently, the 
congruence can also be expressed in the terms that a and b belong to the same 
residue class (mod m). 
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“It seems very simple.” 
“Tt is very simple. But if you don’t know what the key is it’s virtually indecipherable.” 
—Talking to Strange Men, Ruth Rendell 


KEY POINTS 


® AESisa block cipher intended to replace DES for commercial applica- 
tions. It uses a 128-bit block size and a key size of 128, 192, or 256 bits. 

® AES does not use a Feistel structure. Instead, each full round consists of 
four separate functions: byte substitution, permutation, arithmetic opera- 
tions over a finite field, and XOR with a key. 


The Advanced Encryption Standard (AES) was published by the National Institute of 
Standards and Technology (NIST) in 2001. AES is a symmetric block cipher that is 
intended to replace DES as the approved standard for a wide range of applications. 
Compared to public-key ciphers such as RSA, the structure of AES and most 
symmetric ciphers is quite complex and cannot be explained as easily as many other 
cryptographic algorithms. Accordingly, the reader may wish to begin with a simplified 
version of AES, which is described in Appendix 5B. This version allows the reader to 
perform encryption and decryption by hand and gain a good understanding of the 
working of the algorithm details. Classroom experience indicates that a study of this 
simplified version enhances understanding of AES.' One possible approach is to read 
the chapter first, then carefully read Appendix 5B, and then re-read the main body of 
the chapter. 

Appendix H looks at the evaluation criteria used by NIST to select from among 
the candidates for AES, plus the rationale for picking Rijndael, which was the winning 
candidate. This material is useful in understanding not just the AES design but the 
criteria by which to judge any symmetric encryption algorithm. 


5.1 FINITE FIELD ARITHMETIC 


In AES, all operations are performed on 8-bit bytes. In particular, the arithmetic 
operations of addition, multiplication, and division are performed over the finite 
field GF(2°). Section 4.7 discusses such operations in some detail. For the reader 
who has not studied Chapter 4, and as a quick review for those who have, this 
section summarizes the important concepts. 

In essence, a field is a set in which we can do addition, subtraction, multipli- 
cation, and division without leaving the set. Division is defined with the following 


"However, you may safely skip Appendix 5B, at least on a first reading. If you get lost or bogged down in 
the details of AES, then you can go back and start with simplified AES. 
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rule: a/b = a(b~'). An example of a finite field (one with a finite number of ele- 
ments) is the set Z, consisting of all the integers {0,1, ...,p — 1}, where p isa 
prime number and in which arithmetic is carried out modulo p. 

Virtually all encryption algorithms, both conventional and public-key, involve 
arithmetic operations on integers. If one of the operations used in the algorithm is 
division, then we need to work in arithmetic defined over a field; this is because divi- 
sion requires that each nonzero element have a multiplicative inverse. For conve- 
nience and for implementation efficiency, we would also like to work with integers 
that fit exactly into a given number of bits, with no wasted bit patterns. That is, we 
wish to work with integers in the range 0 through 2” — 1, which fit into an n-bit 
word. Unfortunately, the set of such integers, Z>, using modular arithmetic, is not a 
field. For example, the integer 2 has no multiplicative inverse in Z>», that is, there is 
no integer b, such that 2b mod 2” = 1. 

There is a way of defining a finite field containing 2” elements; such a field is 
referred to as GF(2”). Consider the set, S, of all polynomials of degree n — 1 or less 
with binary coefficients. Thus, each polynomial has the form 


n—1 
f(x) = Ay—yx | + Aypx”? +o Hoax + ay = Sax 
i=0 


where each a; takes on the value 0 or 1. There are a total of 2” different polynomials 
in S. For n = 3, the 2° = 8 polynomials in the set are 

O x a etx 

1 xt1 +1 P4+x4+1 


With the appropriate definition of arithmetic operations, each such set S is a 
finite field. The definition consists of the following elements. 


1. Arithmetic follows the ordinary rules of polynomial arithmetic using the basic 
rules of algebra with the following two refinements. 


N 


. Arithmetic on the coefficients is performed modulo 2. This is the same as the 
XOR operation. 


3. If multiplication results in a polynomial of degree greater than n — 1, then the 
polynomial is reduced modulo some irreducible polynomial m(x) of degree n. 
That is, we divide by m(x) and keep the remainder. For a polynomial f(x), the 
remainder is expressed as r(x) = f(x)modm(x). A polynomial m(x) is called 
irreducible if and only if m(x) cannot be expressed as a product of two poly- 
nomials, both of degree lower than that of m(x). 


For example, to construct the finite field GF(2*), we need to choose an irre- 
ducible polynomial of degree 3. There are only two such polynomials: (x* + x? + 1) 
and (x* + x + 1). Addition is equivalent to taking the XOR of like terms. Thus, 
(x+1)+x=1. 

A polynomial in GF(2”) can be uniquely represented by its n binary coeffi- 
cients (d,—14,—2 ... 4). Therefore, every polynomial in GF(2”) can be represented by 
an n-bit number. Addition is performed by taking the bitwise XOR of the two n-bit 
elements. There is no simple XOR operation that will accomplish multiplication in 
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GF(2”). However, a reasonably straightforward, easily implemented, technique is 
available. In essence, it can be shown that multiplication of a number in GF(2”) by 2 
consists of a left shift followed by a conditional XOR with a constant. Multiplication 
by larger numbers can be achieved by repeated application of this rule. 

For example, AES uses arithmetic in the finite field GF(2°) with the irreducible 
polynomial m(x) = x® + x* + x° + x + 1.Consider two elements A = (aja ... ad) 
and B = (b7be...b,bo). The sum A + B = (c7Cp...cC\Co), where c; = a; @ bj. 
The multiplication {02}*A equals (dag...a,;a)90) if a;7=O0 and equals 
(dg... 4,490) @ (00011011) ifa, = 1. 

To summarize, AES operates on 8-bit bytes. Addition of two bytes is defined as 
the bitwise XOR operation. Multiplication of two bytes is defined as multiplication 
in the finite field GF(28), with the irreducible polynomial? m(x) = x® + xt + x°+ 
x + 1. The developers of Rijndael give as their motivation for selecting this one of 
the 30 possible irreducible polynomials of degree 8 that it is the first one on the list 
given in [LIDL94]. 


5.2 AES STRUCTURE 


General Structure 


Figure 5.1 shows the overall structure of the AES encryption process. The cipher 
takes a plaintext block size of 128 bits, or 16 bytes. The key length can be 16, 24, or 32 
bytes (128, 192, or 256 bits). The algorithm is referred to as AES-128, AES-192, or 
AES-256, depending on the key length. 

The input to the encryption and decryption algorithms is a single 128-bit block. 
In FIPS PUB 197, this block is depicted as a 4 X 4 square matrix of bytes. This block 
is copied into the State array, which is modified at each stage of encryption or decryp- 
tion. After the final stage, State is copied to an output matrix. These operations are 
depicted in Figure 5.2a. Similarly, the key is depicted as a square matrix of bytes. This 
key is then expanded into an array of key schedule words. Figure 5.2b shows the 
expansion for the 128-bit key. Each word is four bytes, and the total key schedule is 
44 words for the 128-bit key. Note that the ordering of bytes within a matrix is by col- 
umn. So, for example, the first four bytes of a 128-bit plaintext input to the encryption 
cipher occupy the first column of the in matrix, the second four bytes occupy the 
second column, and so on. Similarly, the first four bytes of the expanded key, which 
form a word, occupy the first column of the w matrix. 

The cipher consists of N rounds, where the number of rounds depends on the 
key length: 10 rounds for a 16-byte key, 12 rounds for a 24-byte key, and 14 rounds 
for a 32-byte key (Table 5.1). The first N — 1 rounds consist of four distinct trans- 
formation functions: SubBytes, ShiftRows, MixColumns, and AddRoundKey, which 
are described subsequently. The final round contains only three transformations, 
and there is a initial single transformation (AddRoundKey) before the first round, 


In the remainder of this discussion, references to GF(2) refer to the finite field defined with this 
polynomial. 
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Plaintext—16 bytes (128 bits) Key—M bytes 


EE se Ty acnani (Aiceeee 
Y. 
Input state Key 
(16 bytes) Round 0 key (M bytes) 
(16 bytes) 


MZ 
Initial transformation $F 


State after y. 
initial 
transformation 
(16 bytes) 


Round 1 Round 1 key 


(4 transformations) (16 bytes) 


y. 
Round 1 
output state 
(16 bytes) 
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= 
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< 
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i= 
x 
o 
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iS 


Round N-1 Round N - 1 key 


(4 transformations) (16 bytes) 
Round N -1 
output state 
(16 bytes) 
Round N key 
Round NV (16 bytes) 


(3 transformations) 


Final state Key 
(16 bytes) No.of | Length 
rounds (bytes) 


CITT TTT tr tr Tt) 
Cipehertext—16 bytes (128 bits) 


Figure 5.1 AES Encryption Process 


which can be considered Round 0. Each transformation takes one or more 4 X 4 
matrices as input and produces a 4 X 4 matrix as output. Figure 5.1 shows that the 
output of each round is a 4 X 4 matrix, with the output of the final round being the 
ciphertext. Also, the key expansion function generates N + 1 round keys, each of 
which is a distinct 4 X 4 matrix. Each round key serve as one of the inputs to the 
AddRoundKey transformation in each round. 


cSt 


ing | ing | ing | ini Soo | Sor | So2 | S03 Soo | Sor | So2 | S03 OUutg | Outs | OUutg | Out). 
in, ins | iNg | in Sio | Sin | Si2 } S13 Sio | Sin | Si2 } S13 out; | outs | OUfg | out); 
SE anil REESE > —— 
Ing ing ing | inyy 52.0 $21 52.9 $23 52.0 $21 52.2 $23 OUly | Outs | OUt\g | OUt\4 
inz | inz | iny | ins $39 | 531 | 832 | 533 $39 | 531 | 832 | 533 Outs | outz | Out, | Out)s 
(a) Input, state array, and output 
ko kg kg | kip 
ky ks ky | ky3 
—_—— > |) 1 | mae Wan | Wa3 
ky ke | kio | kia 
ky | ky | ku | fis 


Figure 5.2 


AES Data Structures 


(b) Key and expanded key 


Table 5.1 AES Parameters 


5.2 / AES STRUCTURE 153 


Key Size (words/bytes/bits) 4/16/128 6/24/192 8/32/256 


Plaintext Block Size (words/bytes/bits) 4/16/128 4/16/128 4/16/128 


Number of Rounds 10 1; 14 


Round Key Size (words/bytes/bits) 4/16/128 4/16/128 4/16/128 


Expanded Key Size (words/bytes) 44/176 52/208 60/240 


Detailed Structure 


Figure 5.3 shows the AES cipher in more detail, indicating the sequence of transfor- 
mations in each round and showing the corresponding decryption function. As was 
done in Chapter 3, we show encryption proceeding down the page and decryption 
proceeding up the page. 


Before delving into details, we can make several comments about the overall 


AES structure. 


1. 


nN 


1] 


6. 


One noteworthy feature of this structure is that it is not a Feistel structure. 
Recall that, in the classic Feistel structure, half of the data block is used to 
modify the other half of the data block and then the halves are swapped. AES 
instead processes the entire data block as a single matrix during each round 
using substitutions and permutation. 


. The key that is provided as input is expanded into an array of forty-four 32-bit 


words, w[i]. Four distinct words (128 bits) serve as a round key for each round; 
these are indicated in Figure 5.3. 


. Four different stages are used, one of permutation and three of substitution: 


e Substitute bytes: Uses an S-box to perform a byte-by-byte substitution of 
the block 


e ShiftRows: A simple permutation 
e MixColumns: A substitution that makes use of arithmetic over GF(2°) 


e AddRoundKey: A simple bitwise XOR of the current block with a portion 
of the expanded key 


. The structure is quite simple. For both encryption and decryption, the cipher 


begins with an AddRoundKey stage, followed by nine rounds that each includes 
all four stages, followed by a tenth round of three stages. Figure 5.4 depicts the 
structure of a full encryption round. 


. Only the AddRoundKey stage makes use of the key. For this reason, the cipher 


begins and ends with an AddRoundKey stage. Any other stage, applied at the 
beginning or end, is reversible without knowledge of the key and so would add 
no security. 


The AddRoundKey stage is, in effect, a form of Vernam cipher and by itself 
would not be formidable. The other three stages together provide confusion, 
diffusion, and nonlinearity, but by themselves would provide no security because 
they do not use the key. We can view the cipher as alternating operations of XOR 


> 
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Key 
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Figure 5.3. AES Encryption and Decryption 


encryption (AddRoundKey) of a block, followed by scrambling of the block (the 


other three stages), followed by XOR encryption, and so on. This scheme is both 
efficient and highly secure. 


Each stage is easily reversible. For the Substitute Byte, ShiftRows, and 
MixColumns stages, an inverse function is used in the decryption algorithm. For 
the AddRoundKey stage, the inverse is achieved by XORing the same round key 
to the block, using the result that A © B® B=A. 


As with most block ciphers, the decryption algorithm makes use of the 
expanded key in reverse order. However, the decryption algorithm is not 
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State | EE 


SubBytes 


State 


ShiftRows 


State 


MixColumns 


State 


State 


Figure 5.4 AES Encryption Round 


identical to the encryption algorithm. This is a consequence of the particular 
structure of AES. 


9. Once it is established that all four stages are reversible, it is easy to verify that 
decryption does recover the plaintext. Figure 5.3 lays out encryption and 
decryption going in opposite vertical directions. At each horizontal point 
(e.g., the dashed line in the figure), State is the same for both encryption and 
decryption. 


10. The final round of both encryption and decryption consists of only three 
stages. Again, this is a consequence of the particular structure of AES and is 
required to make the cipher reversible. 


5.3 AES TRANSFORMATION FUNCTIONS 


We now turn to a discussion of each of the four transformations used in AES. For 
each stage, we describe the forward (encryption) algorithm, the inverse (decryption) 
algorithm, and the rationale for the stage. 


156 CHAPTER 5 / ADVANCED ENCRYPTION STANDARD 


Substitute Bytes Transformation 


FORWARD AND INVERSE TRANSFORMATIONS The forward substitute byte 
transformation, called SubBytes, is a simple table lookup (Figure 5.5a). AES 
defines a 16 X 16 matrix of byte values, called an S-box (Table 5.2a), that 
contains a permutation of all possible 256 8-bit values. Each individual byte of 
State is mapped into a new byte in the following way: The leftmost 4 bits of the 
byte are used as a row value and the rightmost 4 bits are used as a column value. 
These row and column values serve as indexes into the S-box to select a unique 8-bit 
output value. For example, the hexadecimal value? {95} references row 9, column 5 


(a) Substitute byte transformation 


(b) Add round key transformation 
Figure 5.5 AES Byte-Level Operations 


3In FIPS PUB 197, a hexadecimal number is indicated by enclosing it in curly brackets. We use that 
convention in this chapter. 
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of the S-box, which contains the value {2A}. Accordingly, the value {95} is mapped 
into the value {2A}. 
Here is an example of the SubBytes transformation: 


EA | 04 | 65 | 85 87 | F2 | 4D | 97 
83 | 45 | 5D | 96 EC | 6E | 4C | 90 
SC | 33 | 98 | BO = 4A | C3 | 46 | E7 
FO | 2D | AD| CS 8C | D8 | 95 | A6 


The S-box is constructed in the following fashion (Figure 5.6a). 


Byte at row y, 
column x 
initialized to yx 


Byte at row y, 
column x 
initialized to yx 


Byte to bit 
column vector 


Inverse 
in GF(2°) 


Byte to bit bo] [0 0 1.0 0 1 O 1)fbo] Jt] 
column vector b, 1001 00 1 Offb, 0 
by 0100 1 0 0 I)jb, 1 
b, 1010 01 0 Offb 0 
ns 3 | as 
bo 100 0 1 1 1F IIfbo} Jl by} |9 1 0 1 0 0 1 Offby} JO 
bh} ff 100 0 1 1 1h} fl bs 00 10 1 0 0 Iy)}bs} }0 
b,| |1 1 10 0 0 1 I}fby} JO bs} |1 09 0 1 0 1 0 Offb,} JO 
b|_|} 1 1 10 0 0 Ifa} Jo b,| [0 1 00 1:0 1 Ojfd,} [0] 
b,| {1 1 1 1 1 0 0 Offda]” jo 
bs Oo 1 1 21 1 1:0 Offds 1 
be 00 1 1 1 1 LT Offbs 1 Bit column 
b,{ [0 0 O 1 11 1 Id, 0 vector to byte 
Bit column Inverse 
vector to byte in GF(28) 
(a) Calculation of byte at (a) Calculation of byte at 
row y, column x of S-box row y, column x of IS-box 


Figure 5.6 | Constuction of S-Box and IS-Box 


N 
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. Initialize the S-box with the byte values in ascending sequence row by row. 


The first row contains {00}, {01}, {02},..., {OF}; the second row contains 
{10}, {11}, etc.; and so on. Thus, the value of the byte at row y, column x is {yx}. 


. Map each byte in the S-box to its multiplicative inverse in the finite field GF(2°); 


the value {00} is mapped to itself. 


. Consider that each byte in the S-box consists of 8 bits labeled (b7, be, bs, bg, b3, 


bo, b1, bo). Apply the following transformation to each bit of each byte in the 
S-box: 


bi = b; © byi+4) moas DB OG+5) moas O Bii+6) moas © B(i+7) moas © Ci (5.1) 


where c¢; is the ith bit of byte c with the value {63}; that is, (c7cgc5c4c3C2C1C9) = 
(01100011). The prime (’) indicates that the variable is to be updated by the 
value on the right. The AES standard depicts this transformation in matrix form 
as follows. 


bly i 6 OO 2 tT 2 TP hy 1 
bi 1100011 1//b, 1 
bi, 1110001 1/)b 0 
bs}_}1 1 1 1 0 0 0 1)]53]}, Jo (ee) 
bi 111110 0 Of} b, 0 
bi 011 1 1 21 0 Of] ds; 1 
bi 00 1 1 1 21 1 Of] dg 1 
bi d,.0 © 2 4° 4 4 TIS 0 


Equation (5.2) has to be interpreted carefully. In ordinary matrix multiplica- 


tion,’ each element in the product matrix is the sum of products of the elements of 


one row and one column. In this case, each element in the product matrix is the 
bitwise XOR of products of elements of one row and one column. Furthermore, the 
final addition shown in Equation (5.2) is a bitwise XOR. Recall from Section 4.7 


that the bitwise XOR is addition in GF(2°). 


As an example, consider the input value {95}. The multiplicative inverse in 


GF(2°) is {95}! = {8A}, which is 10001010 in binary. Using Equation (5.2), 


100 6 1 t 2 i/o 1 1 1 0 
i 0 OO. 2 ob D4 1 0 1 1 
1110001 14/0 0 0 0 0 
it 2 4 Oo ON Oo} 1 Oo} 1 
1111100 ollfo/Plol~sol®@}o] =] o 
oi it i io ole 1 0 it 1 
0 1 ttt 2 O//0 1 1 1 0 
OO 0 2h a1 29 0 0 0 0 


‘For a brief review of the rules of matrix and vector multiplication, refer to Appendix E. 
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The result is {2A}, which should appear in row {09} column {05} of the S-box. 
This is verified by checking Table 5.2a. 

The inverse substitute byte transformation, called InvSubBytes, makes use 
of the inverse S-box shown in Table 5.2b. Note, for example, that the input {2A} 
produces the output {95}, and the input {95} to the S-box produces {2A}. The 
inverse S-box is constructed (Figure 5.6b) by applying the inverse of the transfor- 
mation in Equation (5.1) followed by taking the multiplicative inverse in GF(2°). 
The inverse transformation is 


bi = bii+2) mod 8 © Dii+s) mod 8 © bii+7) moas ® di 


where byte d = {05}, or 00000101. We can depict this transformation as follows. 


bj 001 00 1 0 1][fb 1 
bi 1001001 O;]b 0 
b} 01001 0 0 1]/d 1 
bs)_|1 0 1 0 0 1 0 OF} b&] Jo 
bj 0101001 Off & 0 
bi 001 01 0 0 1] ds 0 
bé 100 10 1 0 Off bg 0 
bs 01001 01 0|ld, 0 


To see that InvSubBytes is the inverse of SubBytes, label the matrices in 
SubBytes and InvSubBytes as X and B, respectively, and the vector versions of con- 
stants c and d as C and D, respectively. For some 8-bit vector B, Equation (5.2) 
becomes B’ = XB @ C. We need to show that Y(XB @ C) @ D = B. To multiply 
out, we must show YXB @ YC @ D = B. This becomes 


COL Oo TOU be OO Tt 4 1h 
i106 1 60 0 7 Ol|t 106 Oo oO 4 T Lib 
O10 0 100 T//4 2 1 6 OO Tf IIe 
ioio60 t 0 @)|4- 1.4 14 6-6 & 1))h 
0101001 0\/1 1114100 0l4,|% 
001 01 0 0 1//0 11 4 14 1 0 Off ds 
100101 0 0]/0 01 1 1 1 1 Off bg 
Of CO 1 0 1 OO OO 1 1 tf 4 LSB 
001001 014f1 1 
i 6:0 2 6 O@ 2 @) Ia 0 
O10 0 1.0 06 1/0 it 
101 00 1 0 0/]}0 0}. 
0101001 oflo;Plol> 
00101 0 0 1441 0 
10 0 1 0 4’ 0 0) 1/4 0 
010 01 0 1 0/0 0 
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100 00 0 0 O]f& 1 1 bo 
0100000 Olla, 0 0 b, 
00100 0 0 O0llb 1 i b> 
00 oO 7 oO oO O}]b 0 0 b; 
000010 0 ollm}Plol®]o)]= |, 
000001 0 Of]; 0 0 bs 
000 00 01 Of] b 0 0 be 
000 0 0 0 0 1]lb, 0 0 by 


We have demonstrated that YX equals the identity matrix, and the YC = D, 
so that YC @ D equals the null vector. 


RATIONALE The S-box is designed to be resistant to known cryptanalytic attacks. 
Specifically, the Rijndael developers sought a design that has a low correlation 
between input bits and output bits and the property that the output is not a linear 
mathematical function of the input [DAEM01]. The nonlinearity is due to the use 
of the multiplicative inverse. In addition, the constant in Equation (5.1) was 
chosen so that the S-box has no fixed points [S-box(a) = a] and no “opposite 
fixed points” [S-box(a) = a], where a is the bitwise complement of a. 

Of course, the S-box must be invertible, that is, IS-box[S-box(a)] = a. 
However, the S-box does not self-inverse in the sense that it is not true that 
S-box(a) =IS-box(a). For example, S-box({95}) = {2A}, but IS-box({95}) = {AD}. 


ShiftRows Transformation 


FORWARD AND INVERSE TRANSFORMATIONS The forward shift row transformation, 
called ShiftRows, is depicted in Figure 5.7a. The first row of State is not altered. For 
the second row, a 1-byte circular left shift is performed. For the third row, a 2-byte 
circular left shift is performed. For the fourth row, a 3-byte circular left shift is 
performed. The following is an example of ShiftRows. 


87 | F2 | 4D | 97 87 | F2 | 4D | 97 
EC | 6E | 4C | 90 6E | 4C | 90 | EC 
4A | C3 | 46 | E7 = 46 | E7 | 4A {| C3 
8C | D8 | 95 | A6 A6 | 8C | D8 | 95 


The inverse shift row transformation, called InvShiftRows, performs the circu- 
lar shifts in the opposite direction for each of the last three rows, with a 1-byte 
circular right shift for the second row, and so on. 


RATIONALE The shift row transformation is more substantial than it may first 
appear. This is because the State, as well as the cipher input and output, is treated 
as an array of four 4-byte columns. Thus, on encryption, the first 4 bytes of the 
plaintext are copied to the first column of State, and so on. Furthermore, as 
will be seen, the round key is applied to State column by column. Thus, a row 
shift moves an individual byte from one column to another, which is a linear 
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50,0 | 50,1 | $0.2 | $0,3 Prenve™ $0,0 | 0,1 | $0.2 | 0,3 
E\VEN 
S10] S11 | $12| 513|-— > | 511 | 51.2 | 513 | S10 
2 
$2.0 | S21 | 52,2 | $2.3 | — | 822 | $2.3 | $2.0] S21 
a ae 
$3,0 | 53.1 | $3.2 | $33] ee |) | O20|) S| a2 
(a) Shift row transformation 
2311 
1231 a 
11 23)" | 
yi[3 112 
50,0 | So,1 | 50,2 | $0,3 50.0 80,1 50.2 50,3 
S10} Sit] 51,2 | $13 S\o Sha Sip S13 
52,0 | $2.1 | 52,2 | $23 50 9d So 53 
53,0 | 3,1 | 53,2 | $33 53,9 531 532 533 


(b) Mix column transformation 


Figure 5.7. AES Row and Column Operations 


distance of a multiple of 4 bytes. Also note that the transformation ensures that 
the 4 bytes of one column are spread out to four different columns. Figure 5.4 
illustrates the effect. 


MixColumns Transformation 


FORWARD AND INVERSE TRANSFORMATIONS The forward mix column transformation, 
called MixColumns, operates on each column individually. Each byte of a column is 
mapped into a new value that is a function of all four bytes in that column. The 
transformation can be defined by the following matrix multiplication on State 
(Figure 5.7b): 


02 03 O1 O1 Soo Sor $02 $03 S00 S01 «S02 S03 

01 02 03 Ol Sio S110 812 813 | _ Sio Str S12 S13 (5.3) 
O01 O01 02 03) 529 S21 S22 S23 Soo 591 $22 $23 ; 
03 O01 O1 02 S30 6531 $32 $33 330 S31 932 933 


Each element in the product matrix is the sum of products of elements of one row and 
one column. In this case, the individual additions and multiplications” are performed 


>We follow the convention of FIPS PUB 197 and use the symbol e to indicate multiplication over the 
finite field GF(2°) and © to indicate bitwise XOR, which corresponds to addition in GF(2°). 
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in GF(28). The MixColumns transformation on a single column of State can be 
expressed as 


50,7 = (2° 50,j) B 3° 51,)) © 52; @ $3,; 
S47 = 50,7, ® (2° 51,) © B* 82,;) O53, 
55,7 = 80,7 B 51,7 © (2° 52, ;) @ (3°53, ;) 
53,7 = (3°50, ;) © 51,7 © 52,7 D (2°53, ) 


The following is an example of MixColumns: 


(5.4) 


87 | F2 | 4D | 97 47 | 40 | A3 | 4C 
6E | 4C | 90 | EC 37 | D4 | 70 | 9F 
46 | E7 | 4A | C3 => 94 | E4 | 3A | 42 
Aé | 8C | D8 | 95 ED | AS | A6é | BC 


Let us verify the first column of this example. Recall from Section 4.7 that, in 
GF(2°), addition is the bitwise XOR operation and that multiplication can be per- 
formed according to the rule established in Equation (4.14). In particular, multipli- 
cation of a value by x (i.e., by {02}) can be implemented as a 1-bit left shift followed 
by a conditional bitwise XOR with (0001 1011) if the leftmost bit of the original 
value (prior to the shift) is 1. Thus, to verify the MixColumns transformation on the 
first column, we need to show that 


({02} * {87}) © ({03} * {6E}) @ {46} @ {A} = a7 
{87} ® ({02} + {6E}) @ ({03} * {46}) @ {AG} = {37} 
{87} ® {6E} ® ({02} » {46}) © ({03} * {A6}) = {94} 
({03} * {87}) © {6E} @ {46} ® ({02}* {A6}) = {ED} 


For the first equation, we have {02} * {87} = (0000 1110) @ (0001 1011) = 
(0001 0101) and {03} * {6E} = {6E} @ ({02} * {6E}) = (0110 1110) @ (1101 1100) = 
(10110010). Then, 


{02}*{87} = 0001 0101 
{03}*{6E} = 1011 0010 
{46} = 0100 0110 
{A6} = 1010 0110 


0100 0111 = {47} 


The other equations can be similarly verified. 
The inverse mix column transformation, called InvMixColumnas, is defined by 
the following matrix multiplication: 


OE OB OD 09 |] S00 Son Soz S03 S00 S01 802 S03 

¥ rz rs t 
09 OE OB OD S10 S110 8120813 |_| $10 811 812813 (5.5) 
OD 09 OE OB }) 529 S21 S22 S23 S20 S21 S22 $23 


OB OD 09 OE 53.0 S34 532 533 S50 534 S30 533 
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It is not immediately clear that Equation (5.5) is the inverse of Equation (5.3). 
We need to show 


OE OB OD 09 02 03 01 01 }} Soo Sor So2 S03 Soo 0,1 S02 S03 
09 OE OB OD |} 01 02 03 O01 )) sio Sig Si2 S13} | Sio Sia S12 S13 
OD 09 OE OB 01 O01 02 03 |} S209 S24 S22 S23 — $20 S21 S22 $23 
OB OD 09 OE |{.03 O01 01 02] [535 531 S32 533 539 531 S32 833 


which is equivalent to showing 


OE OB OD 09 02 03 O1 OL 
09 OE OB OD]; 01 02 O63 O1 
OD 09 OE OB}; 01 O1 02 03 
0B OD 09 OE/}{03 O1 O1 02 


(5.6) 


ooo rF 
oor oO 
orROS 
a) 


That is, the inverse transformation matrix times the forward transformation 
matrix equals the identity matrix. To verify the first column of Equation (5.6), we 
need to show 


({OE} * {02}) © {OB} @ {OD} @ ({09} * {03}) = {01} 
({09} * {(02}) ® {OE} @ {OB} & ({OD}  {03}) = {00} 
({OD} * {02}) © {09} @ {OE} G ({OB} * {03}) = {00} 
({OB} * {02}) © {OD} @ {09} © {OE} * {03}) = {00} 


For the first equation, we have {OE}+* {02} = 00011100 and {09} > {03} = 
{09} & ({09} + {02}) = 00001001 @ 00010010 = 00011011. Then 


{OE} + {02} = 00011100 


{0B} = 00001011 
{0D} = 00001101 
{09} * {03} = 00011011 

00000001 


The other equations can be similarly verified. 

The AES document describes another way of characterizing the MixColumns 
transformation, which is in terms of polynomial arithmetic. In the standard, 
MixColumns is defined by considering each column of State to be a four-term poly- 
nomial with coefficients in GF(2°). Each column is multiplied modulo (x* + 1) by 
the fixed polynomial a(x), given by 


a(x) = {03}x? + {O1}x? + {O1}x + {02} (5.7) 


Appendix 5A demonstrates that multiplication of each column of State by 
a(x) can be written as the matrix multiplication of Equation (5.3). Similarly, it 
can be seen that the transformation in Equation (5.5) corresponds to treating 
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each column as a four-term polynomial and multiplying each column by D(x), 
given by 


b(x) = {OB}x? + {OD}x” + {09}x + {OE} (5.8) 
It readily can be shown that b(x) = a(x) mod (x* + 1). 


RATIONALE The coefficients of the matrix in Equation (5.3) are based on a linear 
code with maximal distance between code words, which ensures a good mixing 
among the bytes of each column. The mix column transformation combined with the 
shift row transformation ensures that after a few rounds all output bits depend on 
all input bits. See [DAEM99] for a discussion. 

In addition, the choice of coefficients in MixColumns, which are all {01}, { 02}, 
or { 03}, was influenced by implementation considerations. As was discussed, multi- 
plication by these coefficients involves at most a shift and an XOR. The coefficients 
in InvMixColumns are more formidable to implement. However, encryption was 
deemed more important than decryption for two reasons: 


1. For the CFB and OFB cipher modes (Figures 6.5 and 6.6; described in Chapter 6), 
only encryption is used. 


nN 


. As with any block cipher, AES can be used to construct a message authentica- 
tion code (Chapter 12), and for this, only encryption is used. 


AddRoundKey Transformation 


FORWARD AND INVERSE TRANSFORMATIONS In the forward add round key transfor- 
mation, called AddRoundKey, the 128 bits of State are bitwise XORed with the 
128 bits of the round key. As shown in Figure 5.5b, the operation is viewed as a 
columnwise operation between the 4 bytes of a State column and one word of the 
round key; it can also be viewed as a byte-level operation. The following is an 
example of AddRoundKey: 


47 | 40 | A3 | 4C AC | 19 | 28 | 57 EB | 59 | 8B | 1B 
37 | D4 | 70 | 9F 77 | FA | D1 | 5C 40 | 2E | Al | G3 
94 | E4 | 3A |} 42 | @ | 66 | DC} 29 | 00 = | F2} 38 | 13 | 42 
ED | A5 | A6 | BC F3 | 21 | 41 | 6A 1E | 84 | E7 | D6 


The first matrix is State, and the second matrix is the round key. 
The inverse add round key transformation is identical to the forward add 
round key transformation, because the XOR operation is its own inverse. 


RATIONALE The add round key transformation is as simple as possible and affects 
every bit of State. The complexity of the round key expansion, plus the complexity 
of the other stages of AES, ensure security. 

Figure 5.8 is another view of a single round of AES, emphasizing the mecha- 
nisms and inputs of each transformation. 
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State matrix 
at beginning 
of round 


03 Ol Ol 
01 02 03 OL 
O01 O1 02 03 
03 O1 O1 02 


MixColumns matrix 


at end 
of round 


—_—_—_—_—X_/ 


Constant inputs Variable input 
Figure 5.8 Inputs for Single AES Round 


5.4 AES KEY EXPANSION 


Key Expansion Algorithm 


The AES key expansion algorithm takes as input a four-word (16-byte) key and pro- 
duces a linear array of 44 words (176 bytes). This is sufficient to provide a four-word 
round key for the initial AddRoundKey stage and each of the 10 rounds of the 
cipher. The pseudocode on the next page describes the expansion. 

The key is copied into the first four words of the expanded key. The remain- 
der of the expanded key is filled in four words at a time. Each added word w{i] 
depends on the immediately preceding word, w[i — 1], and the word four posi- 
tions back, w[i — 4]. In three out of four cases, a simple XOR is used. For a word 
whose position in the w array is a multiple of 4,a more complex function is used. 
Figure 5.9 illustrates the generation of the expanded key, using the symbol g to 
represent that complex function. The function g consists of the following 
subfunctions. 


KeyExpansion 
{ 


(byte key[16 


word temp 
ere (2 = Of a < Ap aps 


for i = Mle aids 
{ 

temp = w[i - 1]; 
aie (a moc 4 = @) 


w[i-4] 


as 
fs [to 
a] [i 


(a) Overall algorithm 
AES Key Expansion 


Figure 5.9 


1 


cen = 


@® temp 


word w[44]}) 


(key [4*1], 
key [4*14+2], 
key [4*1+3]); 


key [4*14+1], 


SubWord (RotWord 
@ Rcon[i/4]; 


(temp) ) 


(b) Function g 
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1. RotWord performs a one-byte circular left shift on a word. This means that an 


WN 


input word [Bo, By, Bz, B3] is transformed into [B,, By, B3, Bo]. 


. SubWord performs a byte substitution on each byte of its input word, using the 
S-box (Table 5.2a). 


3. The result of steps 1 and 2 is XORed with a round constant, Rcon|j]. 


The round constant is a word in which the three rightmost bytes are always 0. 


Thus, the effect of an XOR of a word with Reon is to only perform an XOR on the left- 
most byte of the word. The round constant is different for each round and is defined as 
Reon{[j] = (RC{[j], 0, 0, 0), with RC[1] = 1, RC[j] = 2* RC[j—1] and with multiplica- 
tion defined over the field GF(2°). The values of RC[j] in hexadecimal are 


j 1 2 3 4 5 6 7 8 9 10 


RC{j] 01 02 04 08 10 20 40 80 1B 36 


For example, suppose that the round key for round 8 is 


EA D2 73 21 B5 8D BA D2 31 2B F5 60 7F 8D 29 2F 


Then the first 4 bytes (first column) of the round key for round 9 are calculated as 
follows: 


i (decimal) 


After XOR 
with Rcon 


After After w([i] = temp 


temp | RotWord SubWord @ wii- 4] 


Rcon (9) 


w[i-4] 


36 


| 7F8D292F| 8D292F7F| SDAS15D2| 18000000 46A515D2 | EAD27321| ACT7766F3 


Rationale 


The Rijndael developers designed the expansion key algorithm to be resistant to 
known cryptanalytic attacks. The inclusion of a round-dependent round constant 
eliminates the symmetry, or similarity, between the ways in which round keys 
are generated in different rounds. The specific criteria that were used are [DAEM99] 


e Knowledge of a part of the cipher key or round key does not enable calcula- 
tion of many other round-key bits. 


e An invertible transformation [i.e., knowledge of any Nk consecutive words of 
the expanded key enables regeneration the entire expanded key (Nk = key 
size in words) |. 


e Speed on a wide range of processors. 


e Usage of round constants to eliminate symmetries. 


Diffusion of cipher key differences into the round keys; that is, each key bit 
affects many round key bits. 


e Enough nonlinearity to prohibit the full determination of round key differ- 
ences from cipher key differences only. 


Simplicity of description. 
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The authors do not quantify the first point on the preceding list, but the idea is 
that if you know less than Nk consecutive words of either the cipher key or one of 
the round keys, then it is difficult to reconstruct the remaining unknown bits. The 
fewer bits one knows, the more difficult it is to do the reconstruction or to determine 
other bits in the key expansion. 


5.5 AN AES EXAMPLE 


We now work through an example and consider some of its implications. Although 
you are not expected to duplicate the example by hand, you will find it informative 
to study the hex patterns that occur from one step to the next. 

For this example, the plaintext is a hexadecimal palindrome. The plaintext, key, 
and resulting ciphertext are 


Results 


Plaintext: 


0123456789abcdef fedcba9876543210 


Key: 


0£1571c947d9e8590cb7add6af7£6798 


££0b844a0853bf£7c6934ab4364148f£b9 


Table 5.3 shows the expansion of the 16-byte key into 10 round keys. As previously 
explained, this process is performed word by word, with each four-byte word occupy- 
ing one column of the word round-key matrix. The left-hand column shows the four 
round-key words generated for each round. The right-hand column shows the steps 


Table 5.3 Key Expansion for AES Example 
Key Words 


Auxiliary Function 


w0 = 
wl = 
w2 = 


ws = 


Of 
47 
Oc 
af 


al 
e8 
ad 
67 


RotWord (w3) = 7£ 67 98 af =x1 
SubWord (x1) =d2 85 46 79 yl 
Rcon(1) = 01 00 00 00 

yl @ Rcon(1) = d3 85 46 79 =z1 


w4 = 


w5 


w0 
w4 
w5 


= w6 


wl 
w2 


z1= 


w3 = 


90 
49 
fe 
81 


37 
df 
72 
15 


bo 
eg 
hig 
a7 


RotWord (w7) = 81 15 a7 38 = x2 
SubWord (x4) = 0c 59 5c 07 = y2 
Recon (2) = 02 00 00 00 

V7) (GB) eal (A) = WE SO) Sel Wi) = 44 


=w4@ z2 = 
w8 @ w5 = 


d2 c9 6b b7 
49 80 b4 5e 
w9 G@ w6 = de 7e c6 61 


@®w7 = e6 ££ d3 c6 


RotWord (w11) = f£ d3 c6 e6 = x3 
SubWord (x2) = 16 66 b4 83 = y3 

Rcon (3) = 04 00 00 00 

y3 @ Reon (3) = 12 66 b4 8e = 23 


wl3 @wi0 = 57 51 ad 06 
w1l4 @ wil = bl ae 7e cO 


Za = c0 BE GE 39 


= G8) 2 Gls O7/ 


RotWord (w15) = ae 7e c0O bl = x4 
SubWord (x3) = e4 £3 ba c8 = y4 
Rcon (4) = 08 00 00 00 

y4 @ Reon (4) =ec £3 ba c8=4 


(Continued) 


Continued 
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Auxiliary Function 


wl6 = 
wl17 = 


w18 


wl9 = 


wl2@ z4 = 2c 5c 65 f1 

w16 G@wi3 = a5 73 Oe 96 
wl7 @wi4 = f2 22 a3 90 
w18 @wi5 = 43 8c dd 50 


RotWord(w19) = 8c dd 50 43 = x5 
SubWord (x4) = 64 cl 53 la=y5 
Rcon(5) = 10 00 00 00 

y5 @Rcon(5) = 74 cl 53 la=2z5 


w20 


w21 = 


w22 
w23 


=wl6@z5 = 58 9d 36 eb 


w20 @wi7 = fd ee 38 7d 
w21@wi8 = 0f cc 9b ed 


=w22@wl9 = 4c 40 46 bd 


RotWord (w23) = 40 46 bd 4c = x6 
SubWord (x5) = 09 5a 7a 29 = y6 

Rcon(6) = 20 00 00 00 

y6 @ Rcon(6) = 29 5a 7a 29 = z6 


w24 
w25 
w26 
w27 


=w20@z6 = 71 c7 4c c2 


= w24 @w21 = 8c 29 74 bf 
= w25 @® w22 
= w26 @ w23 


= w24@ 27 = 37 14 93 48 
= w28 @w25 = bb 3d e7 £7 


83 e5 ef 52 
ef ad a9 ef 


w29 G@ w26 = 38 d8 08 a5 


= w30 ®w27 = £7 7d al 4a 


RotWord (w27) =a5 a9 ef cf = x7 
SubWord (x6) = 06 d3 bf 8a=y7 

Recon (7) = 40 00 00 00 

y7 @ Rcon(7) = 46 d3 df 8a = 27 


RotWord (w31) = 7d al 4a £7 = x8 
SubWord (x7) = ff 32 dé 68 = y8 
Rcon (8) = 80 00 00 00 

y8 @ Rcon(8) =7£ 32 d6 68 = z8 


= w28@ z8 = 48 26 45 20 


w32 @w29 = £3 1b a2 d7 


= w33 @ w30 = cb c3 aa 72 
= w34 @®w32 = 3c be 0b 3 


RotWord (w35) = be 0b 38 3c = x9 
SubWord (x8) = ae 2b 07 eb=y9 
Rcon (9) = 1B 00 00 00 

y9 @ Recon (9) =b5 2b 07 eb= 29 


RotWord (w39) = 6b 41 56 £9 = x10 
SubWord (x9) = 7£ 83 b1 99 = y10 
Recon (10) = 36 00 00 00 

y10 @ Recon (10) = 49 83 bi 99 = z10 


w36 
w37 
w38 
w39 


= w32 @ z9 = fd 0d 42 cb 
= w36 ®w33 = 0e 16 e0 ic 

w37 @w34=c5 d5 4a 6e 
= w38 ®w35 = £9 6b 41 56 


w40 = w36@z10 = b4 8e £3 52 
w41 = w40 @w37 = ba 98 13 4e 
w42 = w41@w38 = 7£ 4d 59 20 
w43 = w42 @w39 = 86 26 18 76 


used to generate the auxiliary word used in key expansion. We begin, of course, with 
the key itself serving as the round key for round 0. 

Next, Table 5.4 shows the progression of State through the AES encryption 
process. The first column shows the value of State at the start of a round. For the first 
row, State is just the matrix arrangement of the plaintext. The second, third, and fourth 
columns show the value of State for that round after the SubBytes, ShiftRows, and 
MixColumns transformations, respectively. The fifth column shows the round key. 
You can verify that these round keys equate with those shown in Table 5.3. The first 
column shows the value of State resulting from the bitwise XOR of State after the 
preceding MixColumns with the round key for the preceding round. 


ect 


alanche E 


If a small change in the key or plaintext were to produce a corresponding small 
change in the ciphertext, this might be used to effectively reduce the size of the 
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»5.4 AES Example 


Start of Round After SubBytes After ShiftRows | After MixColumns Round Key 


01 89 fe 76 Of 47 Oc af 
23 ab dc 54 lS) rey) F/ae 
45 cd ba e8 ad 67 
67 ef 98 Be) els O35 


Oe ce Gye) 7) 8) 
36 72 49 fe 81 
34 25 he 97) alls) 
ae b6 e9 3f a7 


65 Of 49 de e6 
74 c7 80 Ye ff 
TOW SEE b4 c6 d3 
WS) She Be 6 © 


5c 6b 89 57 bt 
7b 72 2£ 51 ae 
b4 34 6b ad 7e 
Samo 67 06 cO 


71 48 a5 £2 43 
i) ele We) AA ie 
26 74 Oe a3 dd 
24 Te O5 0) BY) 


£8 b4 fd Of 4c 
ot or ee cc 40 
ae a5 38 9b 46 
e8 7a ed bd 


72 xe: GS) he 
le 29 e5 a5 
b2 74 ef a9 
00 bf 52 ef 


0a Hoyo) if} aly/ 
dg aicl cl Tel 
ds e7 08 al 
56 £7 a5 4a 


db £3) cb) 3c 
18 1b c3 be 
a8 a2 aa Ob 
fe Cl) WA aie) 


(Continued) 
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Table 5.4 Continued 


Start of Round After SubBytes After ShiftRows | After MixColumns Round Key 


£9 e9 8f 2b 99 le 73 99 le 73 £1 gil 20) se CH fd 0e c5 £9 
1b 34 2£ 08 ekg ale) als ale} al) 0) Che ac 71 8c c4 Od 16 d5 6b 
4f c9 85 49 84 dd 97 97 3b 84 dd 46 65 48 eb 42 e0 4a 

bE bE 781189) 08 08 a7 08 08 0c Ga ake sal G2) cb 1c 6e 56 
cc 3e ff 3b 4b b2 16 4b b2 16 e2 4b 86 8a 36 b4 8e £3 52 
al 67 59 af BA 35 ES) ie) V0) sy bigcbee2iie5a ba 98 13 4e 
04 85 02 aa £2 97 77 ac £2 97 £b £2 £2 af TE 4d 59 20 
al (00) 5£ B23 is} siz) (5s) ele CC 5am > buck 86 26 18 76 
ff 08 69 
Ob 53 34 
84 bf ab 
4a 7c 43 


plaintext (or key) space to be searched. What is desired is the avalanche effect, in 
which a small change in plaintext or key produces a large change in the ciphertext. 

Using the example from Table 5.4, Table 5.5 shows the result when the eighth 
bit of the plaintext is changed. The second column of the table shows the value of 
the State matrix at the end of each round for the two plaintexts. Note that after just 
one round, 20 bits of the State vector differ. After two rounds, close to half the bits 
differ. This magnitude of difference propagates through the remaining rounds. 
A bit difference in approximately half the positions in the most desirable outcome. 
Clearly, if almost all the bits are changed, this would be logically equivalent to 
almost none of the bits being changed. Put another way, if we select two plaintexts 
at random, we would expect the two plaintexts to differ in about half of the bit 
positions and the two ciphertexts to also differ in about half the positions. 

Table 5.6 shows the change in State matrix values when the same plaintext 
is used and the two keys differ in the eighth bit. That is, for the second case, the 
key is 0€1571c947d9e8590cb7add6af7£6798. Again, one round produces a 


Table 5.5 Avalanche Effect in AES: Change in Plaintext 


Number of Bits 
that Differ 


0123456789abcdef fedcba9876543210 
0023456789abcdef fedcba9876543210 


0e3634aece7225b6£26b174ed92b5588 
0£3634aece7225b6£26b174ed92b5588 


657470750£fc7£E3Ec0e8e8ca4dd02a9c 
c4a9ad090fc7£E3Fc0e8e8ca4dd02a9c 


5c7bb49a6b72349b05a2317££46d1294 
fe2ae569f7ee8bb8c1f5a2bb37ef53d5 


(Continued) 


able 5.5 Continued 


Number of Bits 
that Differ 


7115262448dc747e5cdac7227da9bd9c 
ec093d£b7c45343d689017507d485e62 


£867acee8b437a5210c24c1974cffeabc 
43efdb697244d£808e8d9364ee0ae6E5 


721eb200ba06206dcbhd4bce704fab654e 
7b28a5d5ed643287e006c099bb375302 


0ad9d85689f9f77bc1c5£71185e5fb14 
3bc2d8b6798d8ac4fe36a1d891ac181la 


db18a8ffal6d30d5£88b08d777ba4eaa 
9£b8b5452023c70280e5c4bb9e555a4b 


£91b4Lbfe93 4c9bE8E2E85812b084989 
20264e1126b219aef7feb3£9b2d6de40 


ccal04a13e678500fF£59025f3bafaa34 
b56a0341b2290ba7d£dfbddcd8578205 


££0b844a0853b£7c6934ab4364148fb9 
612b89398d0600cde116227ce72433£0 


38) 


61 


68 


64 


67 


65 


61 


able 5.6 Avalanche Effect in AES: Change in Key 


Number of Bits 
that Differ 


0123456789abcdef fedcba9876543210 
0123456789abcdef fedcba9876543210 


0e3634aece7225b6£26b174ed92b5588 
0£3634aece7225b6£26b174ed92b5588 


657470750fc7£E3Ec0e8e8ca4dd02a9c 
c5a9ad090ecT7£E3Ffcle8e8ca4cd02a9c 


5¢7bb49a6b72349b05a2317££46d1294 
90905fa9563356d15£3760£3b8259985 


7115262448dc747e5cdac7227da9bd9c 
18aeb7aa794b3b66629448d575c7cebf 


£867acee8b437a5210c24c1974cffeabc 
£81015£993c978a876ae017cb49e7eec 


721eb200ba06206dcbhd4bce704fab654e 
5955c91b4e769£3cb4a94768e98d5267 


0ad9d85689f9£77bc1c5£71185e5fb14 
dc60a24d137662181e45b8d3726b2920 


db18a8ffal6d30d5£88b08d777ba4eaa 
£e8343b8f88bef66cab7e977d005a03c 


£91b4fbfe93 4c9bF8E2£85812b084989 
da7dad581d1725c5b72fa0f9d9d1366a 


ccal04a13e678500fF£59025f3bafaa34 
Occbh4c66bb£d912£4b511d72996345e0 


££0b844a0853b£7c6934ab4364148£b9 
£c8923ee501a7d207ab670686839996b 
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significant change, and the magnitude of change after all subsequent rounds is 
roughly half the bits. Thus, based on this example, AES exhibits a very strong 
avalanche effect. 

Note that this avalanche effect is stronger than that for DES (Table 3.5), 
which requires three rounds to reach a point at which approximately half 
the bits are changed, both for a bit change in the plaintext and a bit change in 
the key. 


5.6 AES IMPLEMENTATION 


Equivalent Inverse Cipher 


As was mentioned, the AES decryption cipher is not identical to the encryption 
cipher (Figure 5.3). That is, the sequence of transformations for decryption differs 
from that for encryption, although the form of the key schedules for encryption and 
decryption is the same. This has the disadvantage that two separate software or 
firmware modules are needed for applications that require both encryption and 
decryption. There is, however, an equivalent version of the decryption algorithm 
that has the same structure as the encryption algorithm. The equivalent version has 
the same sequence of transformations as the encryption algorithm (with transfor- 
mations replaced by their inverses). To achieve this equivalence, a change in key 
schedule is needed. 

Two separate changes are needed to bring the decryption structure in line 
with the encryption structure. As illustrated in Figure 5.3, an encryption round has 
the structure SubBytes, ShiftRows, MixColumns, AddRoundKey. The standard 
decryption round has the structure InvShiftRows, InvSubBytes, AddRoundKey, 
InvMixColumns. Thus, the first two stages of the decryption round need to 
be interchanged, and the second two stages of the decryption round need to be 
interchanged. 


INTERCHANGING INVSHIFTROWS AND INVSuBByTES InvShiftRows affects the sequence 
of bytes in State but does not alter byte contents and does not depend on byte 
contents to perform its transformation. InvSubBytes affects the contents of bytes 
in State but does not alter byte sequence and does not depend on byte sequence 
to perform its transformation. Thus, these two operations commute and can be 
interchanged. For a given State S;, 


InvShiftRows [InvSubBytes ($;)] = InvSubBytes [InvShiftRows (S;)] 


INTERCHANGING ADDROUNDKEY AND INVMIxCoLumNs The transformations Add- 
RoundKey and InvMixColumns do not alter the sequence of bytes in State. If we 
view the key as a sequence of words, then both AddRoundKey and InvMixColumns 
operate on State one column at a time. These two operations are linear with respect 
to the column input. That is, for a given State S; and a given round key w,, 


InvMixColumns (S;@ w,) = [[nvMixColumns (S;)] @ [InvMixColumns (w))] 


| OE 
09 
0D 
| OB 
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To see this, suppose that the first column of State S; is the sequence 
(Yo. ¥1, Ya» Y3) and the first column of the round key w; is (Ko, ki, k2, k3). Then we 
need to show 


0B OD 09 ][ yo @ko .0E 0B OD 09 JI yo OE OB OD 09 |I ky 
0E 0B OD/|/y,@k,|_ | 09 OE OB OD]| y, 09 OE OB OD|/k, 
09 OE OB]| y@k| | 0D 09 OE OBI] y> ©lop 09 OE OB ko 
0D 09 OE || y;@k; |0B OD 09 OE || y3 0B OD 09 OE || ky 


Let us demonstrate that for the first column entry. We need to show 


[(OE} * (vo © ko)] © HOB} * 1 @ kx] © [{OD} + (2 © ka)] @ [{09} * (vs © &s)] 


= [0E} * yo] © [{OB} * yi] © [{OD} * v2] B [{09} * ys] © 
[(OE} * ko] © [{OB} * ki] © [{OD} + ka]  [{09} + ks] 


This equation is valid by inspection. Thus, we can interchange AddRoundKey and 
InvMixColumns, provided that we first apply InvMixColumns to the round key. 
Note that we do not need to apply InvMixColumns to the round key for the input to the 
first AddRoundKey transformation (preceding the first round) nor to the last 
AddRoundKey transformation (in round 10). This is because these two AddRoundKey 
transformations are not interchanged with InvMixColumns to produce the equivalent 
decryption algorithm. 

Figure 5.10 illustrates the equivalent decryption algorithm. 


Implementation Aspects 


The Rijndael proposal [DAEM99] provides some suggestions for efficient imple- 
mentation on 8-bit processors, typical for current smart cards, and on 32-bit proces- 
sors, typical for PCs. 


8-Bit Processor AES can be implemented very efficiently on an 8-bit processor. 
AddRoundKey is a bytewise XOR operation. ShiftRows is a simple byte-shifting 
operation. SubBytes operates at the byte level and only requires a table of 256 bytes. 

The transformation MixColumns requires matrix multiplication in the field 
GF(2°), which means that all operations are carried out on bytes. MixColumns only 
requires multiplication by {02} and {03}, which, as we have seen, involved simple 
shifts, conditional XORs, and XORs. This can be implemented in a more efficient 
way that eliminates the shifts and conditional XORs. Equation set (5.4) shows the 
equations for the MixColumns transformation on a single column. Using the iden- 
tity {03} *x = ({02}+*x) @ x, we can rewrite Equation set (5.4) as follows. 


Tmp = $0, BD 51,7 B 82, © $3; 
50, = 50, ® Tmp © [2° (50; ® 51,))] 
S17 = 51,,@ Tmp © [2° (51,; © 52,)] (5.9) 
54,5; = $2, @® Tmp @ [2° (52; © 53, ;)] 
53; = 53,;® Tmp © [2° (s3,; @ 50,;)] 


Equation set (5.9) is verified by expanding and eliminating terms. 
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Ciphertext 


w[40, 43] ———H\H———|_ Add round key 


i 


Inverse sub bytes 


i 


Inverse shift rows 


Y 


Inverse mix cols 


| Inverse mix cols }—. Add round key 


w(36, 39] 7 


Y 


| 


Inverse sub bytes 


i 


Inverse shift rows 


Y 


Inverse mix cols 


| Inverse mix cols p> Add round key 


wi4, aol 


Y 


Inverse sub bytes 


Y 


Expand key Inverse shift rows 
wI0, 3] Add round key 
Key Plaintext 


Figure 5.10 | Equivalent Inverse Cipher 


The multiplication by {02} involves a shift and a conditional XOR. Such an imple- 
mentation may be vulnerable to a timing attack of the sort described in Section 3.4. To 
counter this attack and to increase processing efficiency at the cost of some storage, the 
multiplication can be replaced by a table lookup. Define the 256-byte table X2, such 


that X2[/] = {02}¢ 7. Then Equation set (5.9) can be rewritten as 


Tmp = So,j B 51,; O $2,; B83, ; 


50 


41 = 80, ® Tmp ® Xs, @ 51,4 


Sic = 51,,;® Tmp © X2[s1, | © 52, ] 
Sd¢ = $2,;® Tmp @ X2[52 ; @ 3, |] 


53 


j= 83,,@ Tmp @ X2[s3 ; ® 50, j] 


Round 1 


Round 9 


Round 10 
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32-BiT Processor The implementation described in the preceding subsection uses 
only 8-bit operations. For a 32-bit processor, a more efficient implementation can be 
achieved if operations are defined on 32-bit words. To show this, we first define the 
four transformations of a round in algebraic form. Suppose we begin with a State 
matrix consisting of elements a; ; and a round-key matrix consisting of elements k; ;. 
Then the transformations can be expressed as follows. 


SubBytes bis = Slax] 
Co,j bo,j 
ShiftRows ie = oe 
Les, Ee 
| do, 02 03 O01 01][ co; 
MixColumns dij} _| OL 02 03 OL} cj 
dp, j 01 01 02 03] co, 
L d3,, 03 01 01 02]L¢;, 
£6, doi) | Ko,j 
AddRoundKey ie - - ® - 
ej ds; L ks,, 


In the ShiftRows equation, the column indices are taken mod 4. We can com- 
bine all of these expressions into a single equation: 


&0,j 
e1j 
2; 


3.) 


02 03 O1 O1 S[ao,] ko,j 
_ | O01 02 03 O1 |} Slay j-1] ky j 
01 O01 02 03 }) S[aj;-2] © kp j 
03 01 01 02] [| Sfa3,;-3] kj 
02 03 01 
01 02 03 
aa *S[ao,] | © 01 *S[a,, jal | @ 02 * S[ap, j-2] 
03 01 O1 
01 ko, j 
01 ky j 
°Slas a 
® 03 [a3, j 3] | ® ks 
02 ks, 


In the second equation, we are expressing the matrix multiplication as a linear com- 
bination of vectors. We define four 256-word (1024-byte) tables as follows. 
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02 03 01 | 01 
01 02 03 01 

To[x] = 01 Sx] |} Tif] = 01 °S[x] }) To[x] = 02 Six] || TL] 03 ° Six] 
03 01 01 | 02 


Thus, each table takes as input a byte value and produces a column vector (a 32-bit 
word) that is a function of the S-box entry for that byte value. These tables can be 
calculated in advance. 

We can define a round function operating on a column in the following fashion. 


$b,j Ko,j 
54, _ T Ky j 
, = oLS0, jl ©) T [51-1] >) T,[s2j-2] >) T3[3;-3] ) k 
$2, 2,j 
53, j k3 j 


As a result, an implementation based on the preceding equation requires only 
four table lookups and four XORs per column per round, plus 4 Kbytes to store the 
table. The developers of Rijndael believe that this compact, efficient implementation 
was probably one of the most important factors in the selection of Rijndael for AES. 


5.7 RECOMMENDED READING AND WEB SITES 


The most thorough description of AES so far available is the book by the developers of AES, 
[DAEM02]. The authors also provide a brief description and design rationale in [DAEMO01]. 
[LAND04] is a rigorous mathematical treatment of AES and its cryptanalysis. 

Another worked-out example of AES operation, authored by instructors at Massey U., 
New Zealand is available at this book’s Web site. 


DAEM01 Daemen, J., and Rijmen, V. “Rijndael: The Advanced Encryption Standard.” 
Dr. Dobb’s Journal, March 2001. 
Daemen, J., and Rijmen, V. The Design of Rijndael: The Wide Trail Strategy 


DAEMO02 
Explained. New York: Springer-Verlag, 2002. 

LAND04 = Landau, S. “Polynomials in the Nation’s Service: Using Algebra to Design the 
Advanced Encryption Standard.” American Mathematical Monthly, February 2004. 


Recommended Web Sites: 
e AES home page: NIST’s page on AES. Contains the standard plus a number of other 
relevant documents. 


e The AES Lounge: Contains a comprehensive bibliography of documents and papers 
on AES, with access to electronic copies. 
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5.8 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


Advanced Encryption Standard (AES) power analysis S-box 
National Institute of Standards and Technology (NIST) Rindael 


Review Questions 


amu Mn 


Muu mM 
Scm>UIAM ER wW DN 


un 


What was the original set of criteria used by NIST to evaluate candidate AES ciphers? 
What was the final set of criteria used by NIST to evaluate candidate AES ciphers? 
What is the difference between Rijndael and AES? 

What is the purpose of the State array? 

How is the S-box constructed? 

Briefly describe SubBytes. 

Briefly describe ShiftRows. 

How many bytes in State are affected by ShiftRows? 

Briefly describe MixColumns. 

Briefly describe AddRoundKey. 

Briefly describe the key expansion algorithm. 

What is the difference between SubBytes and SubWord? 

What is the difference between ShiftRows and RotWord? 


What is the difference between the AES decryption algorithm and the equivalent 
inverse cipher? 


Problems 


5.1 


In the discussion of MixColumns and InvMixColumns, it was stated that 
b(x) = a 1(x)mod(x* + 1) 


where a(x) = {03}x> + {O1}x? + {O01}x + {02} and b(x) = {OB}x* + {OD}x? + {09}x + 
{OE}. Show that this is true. 

a. What is {01}~! in GF(2°)? 

b. Verify the entry for {01} in the S-box. 

Show the first eight words of the key expansion for a 128-bit key of all zeros. 

Given the plaintext {000102030405060708090AO0BOCODOEOF} and the key 
{01010101010101010101010101010101}: 

a. Show the original contents of State, displayed as a 4 x 4 matrix. 

b. Show the value of State after initial AddRoundKey. 

c. Show the value of State after SubBytes. 

d. Show the value of State after ShiftRows. 

e. Show the value of State after MixColumns. 

Verify Equation (5.11). That is, show that x‘ mod (x* + 1) = x/mod4, 

Compare AES to DES. For each of the following elements of DES, indicate the com- 
parable element in AES or explain why it is not needed in AES. 

a. XOR of subkey material with the input to the f function 

b. XOR of the f function output with the left half of the block 

ce. f function 
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d. permutation P 

e. swapping of halves of the block 

In the subsection on implementation aspects, it is mentioned that the use of tables 
helps thwart timing attacks. Suggest an alternative technique. 

In the subsection on implementation aspects, a single algebraic equation is developed 
that describes the four stages of a typical round of the encryption algorithm. Provide 
the equivalent equation for the tenth round. 

Compute the output of the MixColumns transformation for the following sequence 
of input bytes “67 89 AB CD”. Apply the InvMixColumns transformation to the 
obtained result to verify your calculations. Change the first byte of the input from ‘67’ 
to ‘77’, perform the MixColumns transformation again for the new input, and deter- 
mine how many bits have changed in the output. 

Note: You can perform all calculations by hand or write a program supporting these 
computations. If you choose to write a program, it should be written entirely by you; 
no use of libraries or public domain source code is allowed in this assignment. 

Use the key 1010 0111 0011 1011 to encrypt the plaintext “ok” as expressed in ASCII 
as 0110 1111 0110 1011. The designers of S-AES got the ciphertext 0000 0111 0011 
1000. Do you? 

Show that the matrix given here, with entries in GF(2"), is the inverse of the matrix 
used in the MixColumns step of S-AES. 


(* ll x ) 

x et 
Carefully write up a complete decryption of the ciphertext 0000 0111 0011 1000 using 
the key 1010 0111 0011 1011 and the S-AES algorithm. You should get the plaintext 
we started with in Problem 5.10. Note that the inverse of the S-boxes can be done 
with a reverse table lookup. The inverse of the MixColumns step is given by the 
matrix in the previous problem. 
Demonstrate that Equation (5.9) is equivalent to Equation (5.4). 


Programming Problems 


Create software that can encrypt and decrypt using S-AES. Test data: A binary plaintext 
of 0110 1111 0110 1011 encrypted with a binary key of 1010 0111 0011 1011 should give 
a binary ciphertext of 0000 0111 0011 1000. Decryption should work correspondingly. 


Implement a differential cryptanalysis attack on 1-round S-AES. 


APPENDIX 5A POLYNOMIALS WITH COEFFICIENTS IN GF(2°) 


In Section 4.5, we discussed polynomial arithmetic in which the coefficients are in Z,, 
and the polynomials are defined modulo a polynomial M(x) whose highest power is 
some integer n. In this case, addition and multiplication of coefficients occurred within 
the field Z,,; that is, addition and multiplication were performed modulo p. 


The AES document defines polynomial arithmetic for polynomials of degree 3 


or less with coefficients in GF(2°). The following rules apply. 


1. 


Addition is performed by adding corresponding coefficients in GF(2°). As was 
pointed out Section 4.5, if we treat the elements of GF(2°) as 8-bit strings, then 
addition is equivalent to the XOR operation. So, if we have 


a(x) = a3x° + ax? + ayx + ap (5.10) 
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and 
b(x) = bax? =F bax =F bx =F bo (5.11) 
then 
a(x) + B(x) = (a3 ® b3)x° + (ay @ by)x* + (a, © By)x + (ay ® bo) 


. Multiplication is performed as in ordinary polynomial multiplication with two 
refinements: 


nN 


a. Coefficients are multiplied in GF(2°). 
b. The resulting polynomial is reduced mod (x* + 1). 


We need to keep straight which polynomial we are talking about. Recall 
from Section 4.6 that each element of GF(2°) is a polynomial of degree 7 or less 
with binary coefficients, and multiplication is carried out modulo a polynomial of 
degree 8. Equivalently, each element of GF(2°) can be viewed as an 8-bit byte 
whose bit values correspond to the binary coefficients of the corresponding poly- 
nomial. For the sets defined in this section, we are defining a polynomial ring in 
which each element of this ring is a polynomial of degree 3 or less with coefficients 
in GF(2%), and multiplication is carried out modulo a polynomial of degree 4. 
Equivalently, each element of this ring can be viewed as a 4-byte word whose byte 
values are elements of GF(2°) that correspond to the 8-bit coefficients of the cor- 
responding polynomial. 

We denote the modular product of a(x) and b(x) by a(x) @ b(x). To com- 
pute d(x) = a(x) ® D(x), the first step is to perform a multiplication without the 
modulo operation and to collect coefficients of like powers. Let us express this as 
c(x) = a(x) X b(x). Then 


c(x) = cgx® + e5x> + caxt + €3x3 + cox? + Cyx + CO (5.12) 
where 
Co = a9 ° bo C4 = (43° D1) @ (ay * bz) @ (a, * 53) 
C1 = (a, *° bo) @ (ao * 51) Cs = (3° bz) @ (ap * bs) 
C2 = (a2* bo) @ (a2 bi) @© (ao * ba) C5 = a3°b3 


3 = (43° bo) @ (a2* 51) © (a1 * ba) @ (ao * 53) 
The final step is to perform the modulo operation 
d(x) = c(x) mod (x* + 1) 
That is, d(x) must satisfy the equation 
(x) = [(x* + 1) x q(x] @ d(x) 


such that the degree of d(x) is 3 or less. 
A practical technique for performing multiplication over this polynomial ring 
is based on the observation that 


x mod(x* + 1) = 4" (5.13) 
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If we now combine Equations (5.12) and (5.13), we end up with 


d(x) = c(x) mod (x* + 1) 


= [cox® + c5x° + cgx* + €3x° + Eyx* + Cyx + Co] mod (x* + 1) 


= 03x° + (cr @ c6)x” + (c1 @ e5)x + (co @ Ca) 


Expanding the c; coefficients, we have the following equations for the coefficients 


of d(x). 


dy = (a9* bo) © (43° bi) © (a2 * bz) © (a1 * bs) 
dy = (a;* bo) © (ao* b1) © (43° bz) © (az * bs) 
dy = (a,* bo) © (a1 * b1) © (ao * bz) © (a3 * bs) 
d3 = (a3* bo) ® (a2* bi) © (a1 * bz) ® (40° bs) 


This can be written in matrix form: 


do a 
dy | 
dy 7 a 
dx a3 


MixColumns Transformation 


a3 
a9 
ay 
a 


ag 
a3 
ao 
ay 


(5.14) 


In the discussion of MixColumns, it was stated that there were two equivalent ways 
of defining the transformation. The first is the matrix multiplication shown in 


Equation (5.3), which is repeated here: 


02 03 01 O1]fs0 S01 
01 02 03 O1f) oo 541 
01 OL 02 O3]}} 59 554 
03 O01 OL 02] ] 539 531 


50,2 
54,2 
52,2 
53,2 


50,3 
51,3 
52,3 
53,3 


50,0 
S10 
59,0 
53,0 


50,2 
51,2 
59,9 
53.9 


50,3 
S13 
593 
83.3 


The second method is to treat each column of State as a four-term polynomial 
with coefficients in GF(2°). Each column is multiplied modulo (x* + 1) by the fixed 


polynomial a(x), given by 


a(x) = {03}x3 + {O1}x? + {O1}x + {02} 


From Equation (5.10), we have a; = {03}; a, = {01}; a, = {01}; and ay = {02}. 
For the jth column of State, we have the polynomial col,(x) = 53 jx” + 
Sq, jX° + $1 jx + So; Substituting into Equation (5.14), we can express 


d(x) = a(x) X colj(x) as 


dp a 43 a, a || So; 
dy _ ay ao a3 ag Syj 
dy MQ A A S27 
d3 43° 42 A ao} $3; 


which is equivalent to Equation (5.3). 


03 
02 
O1 
O1 


O1 
03 
02 
01 


S0,j 
S1j 
$2, j 


$3] 
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Multiplication by x 


Consider the multiplication of a polynomial in the ring by x: c(x) = x @ b(x). We have 


c(x) = x @ b(x) = [x X (byx? + box? + byx + bo] mod (x* + 1) 
= (byx* + box? + b,x? + box) mod (x* + 1) 
= bx? 5 byx? oF box at b3 
Thus, multiplication by x corresponds to a 1-byte circular left shift of the 4 bytes in 


the word representing the polynomial. If we represent the polynomial as a 4-byte 
column vector, then we have 


Co 00 00 00 01 ]{[ dy 
c,| | 01 00 00 00]| 
co}! |00 O01 00 00]] d5 
C3 00 00 O01 00]| d; 


APPENDIX 5B SIMPLIFIED AES 


Simplified AES (S-AES) was developed by Professor Edward Schaefer of Santa Clara 
University and several of his students [MUSA03]. It is an educational rather than a 
secure encryption algorithm. It has similar properties and structure to AES with much 
smaller parameters. The reader might find it useful to work through an example by 
hand while following the discussion in this appendix. A good grasp of S-AES will make 
it easier for the student to appreciate the structure and workings of AES. 


Overview 


Figure 5.11 illustrates the overall structure of S-AES. The encryption algorithm 
takes a 16-bit block of plaintext as input and a 16-bit key and produces a 16-bit 
block of ciphertext as output. The S-AES decryption algorithm takes an 16-bit block 
of ciphertext and the same 16-bit key used to produce that ciphertext as input and 
produces the original 16-bit block of plaintext as output. 

The encryption algorithm involves the use of four different functions, or trans- 
formations: add key (Ax), nibble substitution (NS), shift row (SR), and mix column 
(MC), whose operation is explained subsequently. 

We can concisely express the encryption algorithm as a composition® of functions: 


Ax, ° SR ° NS ° Ax, ° MC © SR° NS @ Ax, 


so that Ax, is applied first. 

The encryption algorithm is organized into three rounds. Round 0 is simply an add 
key round; round 1 is a full round of four functions; and round 2 contains only 3 functions. 
Each round includes the add key function, which makes use of 16 bits of key. The initial 
16-bit key is expanded to 48 bits, so that each round uses a distinct 16-bit round key. 


‘Definition: If f and g are two functions, then the function F with the equation y = F(x) = g[f(x)] is 
called the composition of f and g and is denoted as F = g ° f. 
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ENCRYPTION DECRYPTION 
16-bit plaintext 16-bit key 16-bit plaintext 
Add round key w[0, 1] Add round key 
nN 
a) 
Nibble substitution Expand key Inverse nibble sub 5 
iS) 
Y 4 
= Shift row Inverse shift row 
Bo) 
eps -- |-------- = ——— 
ia Mix columns Inverse mix cols 
Add round key wI2, 3] Add round key = 
y E 
Nibble substitution Inverse nibble sub Z 
Ql Y 
3 Shift row Inverse shift row 
Z 
Add round key }«— wi4,5] Add round key 


16-bit ciphertext 


16-bit ciphertext 
Figure 5.11 S-AES Encryption and Decryption 


Each function operates on a 16-bit state, treated as a 2 X 2 matrix of nibbles, 
where one nibble equals 4 bits. The initial value of the State matrix is the 16-bit plain- 
text; State is modified by each subsequent function in the encryption process, produc- 
ing after the last function the 16-bit ciphertext. As Figure 5.12a shows, the ordering of 
nibbles within the matrix is by column. So, for example, the first 8 bits of a 16-bit 


So,0| S0,1 
bybibab; bybobiobi1 


S1o|S 
babsbeby birbibrabis 10)>11 


Bit representation Nibble representation 
(a) State matrix 


Original key Key expansion 


—areouw_er— 


. 
.% K. 


Kok |kokskakskeky kgkok ok kok; 3k yak 5 


WO 
Bit representation SS CT | 
Ko r 2 
Byte representation 
(b) Key 


Figure 5.12. S-AES Data Structures 
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plaintext input to the encryption cipher occupy the first column of the matrix, and the 
second 8 bits occupy the second column. The 16-bit key is similarly organized, but it is 
somewhat more convenient to view the key as two bytes rather than four nibbles 
(Figure 5.12b). The expanded key of 48 bits is treated as three round keys, whose bits 
are labeled as follows: Kg = ko... ky5;.Ky = kyo... k3y;and Ky = kay... kag. 

Figure 5.13 shows the essential elements of a full round of S-AES. 

Decryption is also shown in Figure 5.11 and is essentially the reverse of encryption: 


Ax, ° INS ° ISR ° IMC ° Ax, ° INS ¢ ISR © Ax, 
in which three of the functions have a corresponding inverse function: inverse 
nibble substitution (INS), inverse shift row (ISR), and inverse mix column (IMC). 
S-AES Encryption and Decryption 
We now look at the individual functions that are part of the encryption algorithm. 


App Key The add key function consists of the bitwise XOR of the 16-bit State matrix 
and the 16-bit round key. Figure 5.14 depicts this as a columnwise operation, but it can 
also be viewed as a nibble-wise or bitwise operation. The following is an example. 


A | 4 2 Be > HE 
7 [9 © D {5 A|C 
State matrix Key 


The inverse of the add key function is identical to the add key function, 
because the XOR operation is its own inverse. 


NiBBLE SUBSTITUTION The nibble substitution function is a simple table lookup 
(Figure 5.14). AES defines a 4 X 4 matrix of nibble values, called an S-box 
(Table 5.7a), that contains a permutation of all possible 4-bit values. Each individual 
nibble of State is mapped into a new nibble in the following way: The leftmost 2 bits of 
the nibble are used as a row value, and the rightmost 2 bits are used as a column value. 
These row and column values serve as indexes into the S-box to select a unique 4-bit 
output value. For example, the hexadecimal value A references row 2, column 2 of the 
S-box, which contains the value 0. Accordingly, the value A is mapped into the value 0. 
Here is an example of the nibble substitution transformation. 


8 | 1 6 | 4 


> 


A fe 0 | C 


The inverse nibble substitution function makes use of the inverse S-box shown 
in Table 5.7b. Note, for example, that the input 0 produces the output A, and the 
input A to the S-box produces 0. 


SHirT Row The shift row function performs a one-nibble circular shift of the second 
row of State the first row is not altered (Figure 5.14). The following is an example. 


6 | 4 6 | 4 
0 | C C | 0 


981 


Nibble Shift Mix Add key 
substitution row column 
TO 
Soo K-—> S —_ $8500 2A F500 So,0 —_— wan 50,0 
[-—__ LL | ‘: 
M 
So ——» S Rr} Si Sio -—"| [——| Sto Sio 
To 
Sa. x S Ro] So So. Sout — wan So. 
[-—_ | - 
M 
So oe» § Ro Si Sia -—"| [——»| Si Sia 
State State State State State 


Figure 5.13. S-AES Encryption Round 
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Nibble 
substitution 
o | 51 —— oo } 400 | S01 Shift 
EN TOW 
Sto} Si. |—___ iy | 511 | S10 
Ng 
14 
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ad 41 
' ' : 
50,0 | So, S00 | So,1 Mix 
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; ' 
Sto | Sit Sto | Sia 
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Figure 5.14 S-AES Transformations 


The inverse shift row function is identical to the shift row function, because it 
shifts the second row back to its original position. 


Mix CoLumn The mix column function operates on each column individually. 
Each nibble of a column is mapped into a new value that is a function of both 


Table 5.7 S-AES S-Boxes 


j 


00 01 10 | ll 


(a) S-Box 


(b) Inverse S-Box 


Note: Hexadecimal numbers in shaded boxes; binary numbers in unshaded boxes. 


188 CHAPTER 5 / ADVANCED ENCRYPTION STANDARD 


nibbles in that column. The transformation can be defined by the following matrix 
multiplication on State (Figure 5.14): 


3 Uy 
b 4 50,0 a) - ie “| 
4 Also si Sio S11 


Performing the matrix multiplication, we get 


Soo = Soo ® (4° S10) 
Sio = (4° So0) © Sio 
Soa = Soi @ (4° S11) 
Sia = (4°So1) @ Sit 


Where arithmetic is performed in GF(2*), and the symbol ¢ refers to multiplica- 
tion in GF(2*). Appendix I provides the addition and multiplication tables. The 
following is an example. 


b ‘| 6 | _ E | 
4 1],/C 0O 7 3 
The inverse mix column function is defined as 


i at 4 = Ke *) 
2 9ILsi0 S141 Sio S14 
We demonstrate that we have indeed defined the inverse in the following fashion. 


cose ce x 
2 9 4 if S10 Sq 0 1 51.0 S14 S10 Sq 

The preceding matrix multiplication makes use of the following results in 
GF(2*):9 + (2° 4)=9+8=1and(9 * 4) +2 =2 +42 =0. These operations 
can be verified using the arithmetic tables in Appendix I or by polynomial arithmetic. 


The mix column function is the most difficult to visualize. Accordingly, we 
provide an additional perspective on it in Appendix I. 


Key Expansion For key expansion, the 16 bits of the initial key are grouped into a 
row of two 8-bit words. Figure 5.15 shows the expansion into six words, by the calcu- 
lation of four new words from the initial two words. The algorithm is 


W2 = Wo@® g(W1) = Wo @ Reon(1) @ SubNib(RotNib(w,)) 
W3 = WO Wy 
W4 = W2@ g(W3) = W2 @ Reon(2) @ SubNib(RotNib(w3)) 
Ws = W4@ Ws 


Reon is a round constant, defined as follows: RC[i] = x'*?, so that RC[1] = 
x° = 1000 and RC[2] = x*mod(x* + x + 1) = x + 1 = 0011. RC[i] forms the left- 
most nibble of a byte, with the rightmost nibble being all zeros. Thus, 
Reon(1) = 10000000 and Rcon(2) = 00110000. 

For example, suppose the key is 2D55 = 0010 1101 0101 0101 = wow. 
Then 
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Wo W, 


(a) Overall algorithm (b) Function g 
Figure 5.15 | S-AES Key Expansion 


wz = 00101101 @ 10000000 @ SubNib(01010101) 

= 00101101 G@ 10000000 @& 00010001 = 10111100 
w3 =10111100 @ 01010101 = 11101001 
w4 = 10111100 @ 00110000 @ SubNib(10011110) 

= 10111100 @ 00110000 @& 00101111 = 10100011 
ws = 10100011 @ 11101001 = 01001010 


The S-Box 
The S-box is constructed as follows: 


1. Initialize the S-box with the nibble values in ascending sequence row by row. 
The first row contains the hexadecimal values (0, 1, 2,3); the second row 
contains (4, 5, 6, 7); and so on. Thus, the value of the nibble at row i, column j is 
Mi + j. 
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nN 


. Treat each nibble as an element of the finite field (24) modulo x* + x + 1. 
Each nibble ap a; a2 a3 represents a polynomial of degree 3. 
3. Map each byte in the S-box to its multiplicative inverse in the finite field 
GF(2*) modulo x* + x + 1;the value 0 is mapped to itself. 
4. Consider that each byte in the S-box consists of 4 bits labeled (bo, by, bo, b3). 
Apply the following transformation to each bit of each byte in the S-box. The 
AES standard depicts this transformation in matrix form as 


bi, 1 0 1 1]f bo 1 
j 110 14/0, 0 
ga) = >) 

A id t ols 0 

bs 0 1 1 14/b; 1 


mn 


. The prime (’) indicates that the variable is to be updated by the value on the 
right. Remember that addition and multiplication are being calculated modulo 2. 


Table 5.7a shows the resulting S-box. This is a nonlinear, invertible matrix. The 
inverse S-box is shown in Table 5.7b. 


S-AES Structure 


We can now examine several aspects of interest concerning the structure of AES. 
First, note that the encryption and decryption algorithms begin and end with the 
add key function. Any other function, at the beginning or end, is easily reversible 
without knowledge of the key and so would add no security but just a processing 
overhead. Thus, there is a round 0 consisting of only the add key function. 

The second point to note is that round 2 does not include the mix column func- 
tion. The explanation for this in fact relates to a third observation, which is that 
although the decryption algorithm is the reverse of the encryption algorithm, as 
clearly seen in Figure 5.11, it does not follow the same sequence of functions. Thus, 


Encryption: Ax, ° SR ° NS ° Ax, ° MC * SR NS Ax, 
Decryption: Ax, ° INS ° ISR ° IMC © Ax, ° INS ° ISR © Ax, 


From an implementation point of view, it would be desirable to have the 
decryption function follow the same function sequence as encryption. This allows the 
decryption algorithm to be implemented in the same way as the encryption 
algorithm, creating opportunities for efficiency. 

Note that if we were able to interchange the second and third functions, the 
fourth and fifth functions, and the sixth and seventh functions in the decryption 
sequence, we would have the same structure as the encryption algorithm. Let’s see if 
this is possible. First, consider the interchange of INS and ISR. Given a state N con- 
sisting of the nibbles (No, Ni, N2, N3), the transformation INS(ISR(N)) proceeds as 


(nein, yy 


Where IS refers to the inverse S-Box. Reversing the operations, the transfor- 
mation ISR(INS(N) proceeds as 
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(xe v1) _,(1s1¥a sina) _, (1s1¥a stv) 
Ni. Ng IS[N;] IS[N3] IS[Ns] IS[Ni] 


which is the same result. Thus, INSUSR(NV)) = ISR(INS(N)). 

Now consider the operation of inverse mix column followed by add key 
IMC(Ax,(N)) where the round key K;, consists of the nibbles (ko o, ki, ko, k1,1)- 
Then 


6 alt ao ra te eee ee 
2 9 kyo ky N, N3 2 9/\ki po OM kip ON 


- (3 kyo ® No) ®2(Ki0 © Mi) (Kon @ No) eee 
2(ko0 ® No) ®9(Ki0 ® M1) 2(ko.1 © Nz) © 9( Ki © N53) 
“ak ® 2k) © (9No®B2M1) (9k, O 2k11) B (IN2 © - 


2koo @ 9k1.0 (2No@9IN1)  (2Ko1 @ 9ki1) @ (2N2 @ IN3) 


( )® 
(9ko9 ®2k19) (9koa ee (ee eae 
(2ko0 ®9K10) — (2ko,1 © 9ky1) (2No ®9N1) (2N2 © 9N3) 


-( syle enJOG alin x) 
2 9k kiyJPl2 on, my 


All of these steps make use of the properties of finite field arithmetic. The result 
is that IMC(Ax,(N)) = IMC(K;) © IMC(N). Now let us define the inverse round 
key for round 1 to be IMC(K;) and the inverse add key operation IAx, to be the 
bitwise XOR of the inverse round key with the state vector. Then we have 
IMC(Ax,(N)) = [Ax (IMC(N)). As a result, we can write the following: 


Encryption: Ax, ° SR ° NS ° Ax, ° MC ° SR © NS ° Ax, 
Decryption: Ax, ° INS ° ISR ° IMC ° Ax, ° INS © ISR ° Ax, 
Decryption: Ax, ° ISR © INS ° Aywc(x, ° IMC ° ISR © INS © Ax, 
Both encryption and decryption now follow the same sequence. Note that this 
derivation would not work as effectively if round 2 of the encryption algorithm 
included the MC function. In that case, we would have 
Encryption: Ax, ° MC ° SR © NS ° Ax, ° MC ° SR © NS ° Ax, 


Decryption: Ax, © INS ° ISR. « IMC * Ay © INS © ISR © IMC © Ag 


0 


There is now no way to interchange pairs of operations in the decryption algo- 
rithm so as to achieve the same structure as the encryption algorithm. 
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Many savages at the present day regard their names as vital parts of themselves, 
and therefore take great pains to conceal their real names, lest these should give 
to evil-disposed persons a handle by which to injure their owners. 


—The Golden Bough, Sir James George Frazer 


KEY POINTS 


® Miultiple encryption is a technique in which an encryption algorithm is used 
multiple times. In the first instance, plaintext is converted to ciphertext 
using the encryption algorithm. This ciphertext is then used as input and 
the algorithm is applied again. This process may be repeated through any 
number of stages. 


® Triple DES makes use of three stages of the DES algorithm, using a total 
of two or three distinct keys. 


® A mode of operation is a technique for enhancing the effect of a crypto- 
graphic algorithm or adapting the algorithm for an application, such as 
applying a block cipher to a sequence of data blocks or a data stream. 


® Five modes of operation have been standardized by NIST for use with 
symmetric block ciphers such as DES and AES: electronic codebook 
mode, cipher block chaining mode, cipher feedback mode, output feed- 
back mode, and counter mode. 

® Another important mode, XTS-AES, has been standardized by the IEEE 
Security in Storage Working Group (P1619). The standard describes a 
method of encryption for data stored in sector-based devices where the 
threat model includes possible access to stored data by the adversary. 


This chapter continues our discussion of symmetric ciphers. We begin with the topic of 
multiple encryption, looking in particular at the most widely used multiple-encryption 
scheme: triple DES. 

The chapter next turns to the subject of block cipher modes of operation. We find 
that there are a number of different ways to apply a block cipher to plaintext, each with 
its own advantages and particular applications. 


6.1 MULTIPLE ENCRYPTION AND TRIPLE DES 


Given the potential vulnerability of DES to a brute-force attack, there has been 
considerable interest in finding an alternative. One approach is to design a 
completely new algorithm, of which AES is a prime example. Another alternative, 
which would preserve the existing investment in software and equipment, is to 
use multiple encryption with DES and multiple keys. We begin by examining the 
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simplest example of this second alternative. We then look at the widely accepted 
triple DES (3DES) approach. 


Double DES 


The simplest form of multiple encryption has two encryption stages and two keys 
(Figure 6.1a). Given a plaintext P and two encryption keys K, and K>, ciphertext C 
is generated as 


C= E(K3, E(K,, P)) 
Decryption requires that the keys be applied in reverse order: 
P= D(K,, D(K, C)) 


For DES, this scheme apparently involves a key length of 56 xX 2 = 112 bits, result- 
ing in a dramatic increase in cryptographic strength. But we need to examine the 
algorithm more closely. 


Decryption 
(a) Double encryption 


Decryption 
(b) Triple encryption 


Figure 6.1 Multiple Encryption 
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REDUCTION TO A SINGLE STAGE Suppose it were true for DES, for all 56-bit key values, 
that given any two keys K, and K,, it would be possible to find a key K3 such that 


E(K2, E(Ki, P)) = E(K3, P) (6.1) 


If this were the case, then double encryption, and indeed any number of stages of 
multiple encryption with DES, would be useless because the result would be equiv- 
alent to a single encryption with a single 56-bit key. 

On the face of it, it does not appear that Equation (6.1) is likely to hold. 
Consider that encryption with DES is a mapping of 64-bit blocks to 64-bit blocks. In 
fact, the mapping can be viewed as a permutation. That is, if we consider all 2™ pos- 
sible input blocks, DES encryption with a specific key will map each block into a 
unique 64-bit block. Otherwise, if, say, two given input blocks mapped to the same 
output block, then decryption to recover the original plaintext would be impossible. 
With 2™ possible inputs, how many different mappings are there that generate a 
permutation of the input blocks? The value is easily seen to be 


a = 1.9247380000000000000000 > (ig } 


On the other hand, DES defines one mapping for each different key, for a total 
number of mappings: 


256 < 10!” 


Therefore, it is reasonable to assume that if DES is used twice with different keys, it 
will produce one of the many mappings that are not defined by a single application 
of DES. Although there was much supporting evidence for this assumption, it was 
not until 1992 that the assumption was proven [CAMP92]. 


MEET-IN-THE-MIDDLE ATTACK Thus, the use of double DES results in a mapping 
that is not equivalent to a single DES encryption. But there is a way to attack this 
scheme, one that does not depend on any particular property of DES but that will 
work against any block encryption cipher. 

The algorithm, known as a meet-in-the-middle attack, was first described in 
[DIFF77]. It is based on the observation that, if we have 


c= E(k), E(K,, P)) 
then (see Figure 6.1a) 
x= E(K,, P) = D(K, C) 


Given a known pair, (P, C), the attack proceeds as follows. First, encrypt P for all 2°° 
possible values of K,. Store these results in a table and then sort the table by the 
values of X. Next, decrypt C using all 2© possible values of K>. As each decryption is 
produced, check the result against the table for a match. If a match occurs, then test 
the two resulting keys against a new known plaintext—ciphertext pair. If the two 
keys produce the correct ciphertext, accept them as the correct keys. 

For any given plaintext P, there are 2“ possible ciphertext values that could 
be produced by double DES. Double DES uses, in effect, a 112-bit key, so that 


196 CHAPTER 6 / BLOCK CIPHER OPERATION 
there are 2!” possible keys. Therefore, on average, for a given plaintext P, the 
number of different 112-bit keys that will produce a given ciphertext C is 
2112/2 = 2'8. Thus, the foregoing procedure will produce about 2** false alarms 
on the first (P, C) pair. A similar argument indicates that with an additional 64 bits 
of known plaintext and ciphertext, the false alarm rate is reduced to 2%" = 27!°, 
Put another way, if the meet-in-the-middle attack is performed on two blocks of 
known plaintext-ciphertext, the probability that the correct keys are determined 
is 1 — 2~'°. The result is that a known plaintext attack will succeed against double 
DES, which has a key size of 112 bits, with an effort on the order of 2°© which is 
not much more than the 2* required for single DES. 


Triple DES with Two Keys 


An obvious counter to the meet-in-the-middle attack is to use three stages of 
encryption with three different keys. This raises the cost of the meet-in-the-middle 
attack to 2!””, which is beyond what is practical now and far into the future. 
However, it has the drawback of requiring a key length of 56 X 3 = 168 bits, which 
may be somewhat unwieldy. 

As an alternative, Tuchman proposed a triple encryption method that uses 
only two keys [TUCH79]. The function follows an encrypt-decrypt-encrypt (EDE) 
sequence (Figure 6.1b): 


C= E(k, D(K2, E(K,, P))) 
P = D(K,, E(K2, D(K;, C))) 


There is no cryptographic significance to the use of decryption for the second 
stage. Its only advantage is that it allows users of 3DES to decrypt data encrypted by 
users of the older single DES: 


C= E(K,, DK, E(k, P))) = E(K,, P) 
P= D(K,, E(Ki, D(K,, C))) = D(K,, C) 


3DES with two keys is a relatively popular alternative to DES and has been 
adopted for use in the key management standards ANS X9.17 and ISO 8732.! 

Currently, there are no practical cryptanalytic attacks on 3DES. Coppersmith 
[COPP94] notes that the cost of a brute-force key search on 3DES is on the order of 
2'!2 ~ (5 x 10°°) and estimates that the cost of differential cryptanalysis suffers an 
exponential growth, compared to single DES, exceeding 10°. 

It is worth looking at several proposed attacks on 3DES that, although not 
practical, give a flavor for the types of attacks that have been considered and that 
could form the basis for more successful future attacks. 

The first serious proposal came from Merkle and Hellman [MERKS81]. Their 
plan involves finding plaintext values that produce a first intermediate value of A = 0 


' American National Standard (ANS): Financial Institution Key Management (Wholesale). From its title, 
X9.17 appears to be a somewhat obscure standard. Yet a number of techniques specified in this standard 
have been adopted for use in other standards and applications, as we shall see throughout this book. 
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(Figure 6.1b) and then using the meet-in-the-middle attack to determine the two keys. 
The level of effort is 2°°, but the technique requires 2°° chosen plaintext-ciphertext 
pairs, which is a number unlikely to be provided by the holder of the keys. 

A known-plaintext attack is outlined in [VANO90]. This method is an 
improvement over the chosen-plaintext approach but requires more effort. 
The attack is based on the observation that if we know A and C (Figure 6.1b), 
then the problem reduces to that of an attack on double DES. Of course, 
the attacker does not know A, even if P and C are known, as long as the two keys 
are unknown. However, the attacker can choose a potential value of A and then 
try to find a known (P, C) pair that produces A. The attack proceeds as follows. 


1. Obtain n (P, C) pairs. This is the known plaintext. Place these in a table (Table 1) 
sorted on the values of P (Figure 6.2b). 


2. Pick an arbitrary value a for A, and create a second table (Figure 6.2c) with 
entries defined in the following fashion. For each of the 2*° possible keys K, = i, 
calculate the plaintext value P; that produces a: 


P; = Di, a) 


For each P; that matches an entry in Table 1, create an entry in Table 2 consisting of 
the K;, value and the value of B that is produced for the (P, C) pair from Table 1, 
assuming that value of K;: 


B= DG, C) 
At the end of this step, sort Table 2 on the values of B. 


(a) Two-key triple encryption with candidate pair of keys 


P, C; 
B; Key i 
(b) Table of 2 known (c) Table of intermediate 
plaintext-ciphertext values and candidate 
pairs, sorted on P keys 


Figure 6.2 Known-Plaintext Attack on Triple DES 
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3. We now have a number of candidate values of K, in Table 2 and are in a position 
to search for a value of K,. For each of the 2°° possible keys K, = j, calculate the 
second intermediate value for our chosen value of a: 


By, = Da) 


Ateach step, look up B;in Table 2. If there is a match, then the corresponding key 
i from Table 2 plus this value of j are candidate values for the unknown keys 
(K,, K2). Why? Because we have found a pair of keys (i, ) that produce a known 
(P, C) pair (Figure 6.2a). 

4. Test each candidate pair of keys (i, j) on a few other plaintext-ciphertext pairs. 
If a pair of keys produces the desired ciphertext, the task is complete. If no pair 
succeeds, repeat from step 1 with a new value of a. 


For a given known (P, C), the probability of selecting the unique value of a 
that leads to success is 1/2™. Thus, given n (P, C) pairs, the probability of success 
for a single selected value of a is n/2™. A basic result from probability theory 
is that the expected number of draws required to draw one red ball out of a 
bin containing n red balls and N — n green balls is (NV + 1)/(n + 1) if the balls 
are not replaced. So the expected number of values of a that must be tried is, 
for large n, 

264 +1 264 


i) 
~~ 


n+1 n 


Thus, the expected running time of the attack is on the order of 


(2°) i = 72120—logon 
n 


Triple DES with Three Keys 


Although the attacks just described appear impractical, anyone using two-key 3DES 
may feel some concern. Thus, many researchers now feel that three-key 3DES is the 
preferred alternative (e.g., [KAL1I96a]). Three-key 3DES has an effective key length 
of 168 bits and is defined as 


c= E(Ks, D(K, E(Ki, P))) 
Backward compatibility with DES is provided by putting K3 = K, or K; = Ky». 


A number of Internet-based applications have adopted three-key 3DES, 
including PGP and S/MIME, both discussed in Chapter 18. 


6.2 ELECTRONIC CODE BOOK 


A block cipher takes a fixed-length block of text of length b bits and a key as input 
and produces a b-bit block of ciphertext. If the amount of plaintext to be encrypted is 
greater than b bits, then the block cipher can still be used by breaking the plaintext 


6.2 / ELECTRONIC CODE BOOK 199 


up into b-bit blocks. When multiple blocks of plaintext are encrypted using the same 
key, a number of security issues arise. To apply a block cipher in a variety of applica- 
tions, five modes of operation have been defined by NIST (SP 800-38A). In essence, 
a mode of operation is a technique for enhancing the effect of a cryptographic 
algorithm or adapting the algorithm for an application, such as applying a block 
cipher to a sequence of data blocks or a data stream. The five modes are intended to 
cover a wide variety of applications of encryption for which a block cipher could be 
used. These modes are intended for use with any symmetric block cipher, including 
triple DES and AES. The modes are summarized in Table 6.1 and described in this 
and the following sections. 

The simplest mode is the electronic codebook (ECB) mode, in which plaintext 
is handled one block at a time and each block of plaintext is encrypted using the 
same key (Figure 6.3). The term codebook is used because, for a given key, there is 
a unique ciphertext for every b-bit block of plaintext. Therefore, we can imagine 
a gigantic codebook in which there is an entry for every possible b-bit plaintext 
pattern showing its corresponding ciphertext. 

For a message longer than b bits, the procedure is simply to break the mes- 
sage into b-bit blocks, padding the last block if necessary. Decryption is per- 
formed one block at a time, always using the same key. In Figure 6.3, the plaintext 
(padded as necessary) consists of a sequence of b-bit blocks, P,, Po,..., Py; the 


Table 6.1 Block Cipher Modes of Operation 


Electronic Codebook (ECB) 


Description 


Each block of 64 plaintext bits 
is encoded independently using 
the same key. 


Typical Application 


Secure transmission of 
single values (e.g., an 
encryption key) 


Cipher Block Chaining (CBC) 


The input to the encryption 
algorithm is the XOR of the next 
64 bits of plaintext and the 
preceding 64 bits of ciphertext. 


General-purpose block- 
oriented transmission 


Authentication 


Cipher Feedback (CFB) 


Input is processed s bits at a time. 
Preceding ciphertext is used as 
input to the encryption algorithm 
to produce pseudorandom output, 
which is XORed with plaintext to 
produce next unit of ciphertext. 


General-purpose stream- 
oriented transmission 


Authentication 


Output Feedback (OFB) 


Similar to CFB, except that the 
input to the encryption algorithm 
is the preceding encryption output, 
and full blocks are used. 


Stream-oriented 
transmission over noisy 
channel (e.g., satellite 
communication) 


Counter (CTR) 


Each block of plaintext is XORed 
with an encrypted counter. The 
counter is incremented for each 
subsequent block. 


General-purpose block- 
oriented transmission 


Useful for high-speed 
requirements 
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K 
(b) Decryption 
Figure 6.3. Electronic Codebook (ECB) Mode 
corresponding sequence of ciphertext blocks is Cj, C;, ..., Cy. We can define 
ECB mode as follows. 
ECB | C= E(K,P) pH hug N| P= DEC) j=1,...,N 


The ECB method is ideal for a short amount of data, such as an encryption 
key. Thus, if you want to transmit a DES or AES key securely, ECB is the appropri- 
ate mode to use. 

The most significant characteristic of ECB is that if the same b-bit block of 
plaintext appears more than once in the message, it always produces the same 
ciphertext. 

For lengthy messages, the ECB mode may not be secure. If the message is highly 
structured, it may be possible for a cryptanalyst to exploit these regularities. For exam- 
ple, if it is known that the message always starts out with certain predefined fields, then 
the cryptanalyst may have a number of known plaintext-ciphertext pairs to work with. 
If the message has repetitive elements with a period of repetition a multiple of b bits, 
then these elements can be identified by the analyst. This may help in the analysis or 
may provide an opportunity for substituting or rearranging blocks. 
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6.3 CIPHER BLOCK CHAINING MODE 


To overcome the security deficiencies of ECB, we would like a technique in which 
the same plaintext block, if repeated, produces different ciphertext blocks. A simple 
way to satisfy this requirement is the cipher block chaining (CBC) mode (Figure 6.4). 
In this scheme, the input to the encryption algorithm is the XOR of the current plain- 
text block and the preceding ciphertext block; the same key is used for each block. In 
effect, we have chained together the processing of the sequence of plaintext blocks. 
The input to the encryption function for each plaintext block bears no fixed relation- 
ship to the plaintext block. Therefore, repeating patterns of b bits are not exposed. As 
with the ECB mode, the CBC mode requires that the last block be padded to a full b 
bits if it is a partial block. 

For decryption, each cipher block is passed through the decryption algorithm. 
The result is XORed with the preceding ciphertext block to produce the plaintext 
block. To see that this works, we can write 


C; = E(K, [G-1 © P))) 


Encrypt 


(b) Decryption 
Figure 6.4 Cipher Block Chaining (CFB) Mode 
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Then 
D(K, C)) = D(K, E(K, [G-1 © Pj) 
D(K, OG) = C41 OF 
C4 @ DK, C) = G4 © C1 OP; = P; 
To produce the first block of ciphertext, an initialization vector (IV) is XORed 
with the first block of plaintext. On decryption, the IV is XORed with the output of 


the decryption algorithm to recover the first block of plaintext. The IV is a data 
block that is that same size as the cipher block. We can define CBC mode as 


C; = E(K, [P; @ IV]) P, = D(K, C;) ®IV 


CBC . 5‘ 


The IV must be known to both the sender and receiver but be unpredictable 
by a third party. In particular, for any given plaintext, it must not be possible to pre- 
dict the IV that will be associated to the plaintext in advance of the generation of 
the IV. For maximum security, the IV should be protected against unauthorized 
changes. This could be done by sending the IV using ECB encryption. One reason 
for protecting the IV is as follows: If an opponent is able to fool the receiver into 
using a different value for IV, then the opponent is able to invert selected bits in the 
first block of plaintext. To see this, consider 


C; = E(K, [IV @ Pi) 
P, =IV@D(K, C) 
Now use the notation that X[i] denotes the ith bit of the b-bit quantity X. Then 
Pili] = IVE] © DK, Cyd 
Then, using the properties of XOR, we can state 
Pili’ = IV[q' © DK, CYL 


where the prime notation denotes bit complementation. This means that if an oppo- 
nent can predictably change bits in IV, the corresponding bits of the received value 
of P; can be changed. 

For other possible attacks based on prior knowledge of IV, see [VOYD83]. 

So long as it is unpredictable, the specific choice of IV is unimportant. 
Sp800-38a recommends two possible methods: The first method is to apply the 
encryption function, under the same key that is used for the encryption of the plain- 
text, to a nonce.“ The nonce must be a data block that is unique to each execution of 
the encryption operation. For example, the nonce may be a counter, a timestamp, or 


°NIST SP-800-90 (Recommendation for Random Number Generation Using Deterministic Random Bit 
Generators) defines nonce as follows: A time-varying value that has at most a negligible chance of repeat- 
ing, e.g., a random value that is generated anew for each use, a timestamp, a sequence number, or some 
combination of these. 
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a message number. The second method is to generate a random data block using 
a random number generator. 

In conclusion, because of the chaining mechanism of CBC, it is an appropriate 
mode for encrypting messages of length greater than b bits. 

In addition to its use to achieve confidentiality, the CBC mode can be used for 
authentication. This use is described in Chapter 12. 


6.4 CIPHER FEEDBACK MODE 


For AES, DES, or any block cipher, encryption is performed on a block of b bits. In 
the case of DES, b = 64 and in the case of AES, b = 128. However, it is possible to 
convert a block cipher into a stream cipher, using one of the three modes to be dis- 
cussed in this and the next two sections: cipher feedback (CFB) mode, output feed- 
back (OFB) mode, and counter (CTR) mode. A stream cipher eliminates the need 
to pad a message to be an integral number of blocks. It also can operate in real time. 
Thus, if a character stream is being transmitted, each character can be encrypted and 
transmitted immediately using a character-oriented stream cipher. 

One desirable property of a stream cipher is that the ciphertext be of the same 
length as the plaintext. Thus, if 8-bit characters are being transmitted, each character 
should be encrypted to produce a ciphertext output of 8 bits. If more than 8 bits are 
produced, transmission capacity is wasted. 

Figure 6.5 depicts the CFB scheme. In the figure, it is assumed that the unit of 
transmission is s bits;a common value is s = 8. As with CBC, the units of plaintext 
are chained together, so that the ciphertext of any plaintext unit is a function of all 
the preceding plaintext. In this case, rather than blocks of b bits, the plaintext is 
divided into segments of s bits. 

First, consider encryption. The input to the encryption function is a b-bit shift 
register that is initially set to some initialization vector (IV). The leftmost (most sig- 
nificant) s bits of the output of the encryption function are XORed with the first 
segment of plaintext P, to produce the first unit of ciphertext C,, which is then 
transmitted. In addition, the contents of the shift register are shifted left by s bits, 
and C;, is placed in the rightmost (least significant) s bits of the shift register. This 
process continues until all plaintext units have been encrypted. 

For decryption, the same scheme is used, except that the received ciphertext 
unit is XORed with the output of the encryption function to produce the plaintext 
unit. Note that it is the encryption function that is used, not the decryption func- 
tion. This is easily explained. Let MSB,(X) be defined as the most significant s bits 
of X.Then 


C, = P, ® MSBJE(K, IV)] 
Therefore, by rearranging terms: 
P, = C, © MSBE(K, IV)] 


The same reasoning holds for subsequent steps in the process. 
We can define CFB mode as follows. 


204 CHAPTER 6 / BLOCK CIPHER OPERATION 


Shift register 
b-s bits |s bits 


S bits s bits 
(a) Encryption 


Cy-1 


ee 
S bits s bits 
(b) Decryption 
Figure 6.5 s-bit Cipher Feedback (CFB) Mode 
i = IV i = IV 
— i; = TSB.) (G4 f= 2 f= LSB 0-4) |G f= 2.10 
O; = E(K, Jj) j=l,...,N O; = E(k, I}) j=il,...,N 


C; = P;@®MSB(O) j=1,...,N P, = C,@MSB(O) j=1,...,N 


Although CFB can be viewed as a stream cipher, it does not conform to the 
typical construction of a stream cipher. In a typical stream cipher, the cipher takes as 
input some initial value and a key and generates a stream of bits, which is then 
XORed with the plaintext bits (see Figure 3.1). In the case of CFB, the stream of bits 
that is XORed with the plaintext also depends on the plaintext. 
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6.5 OUTPUT FEEDBACK MODE 


The output feedback (OFB) mode is similar in structure to that of CFB. As can be 
seen in Figure 6.6, it is the output of the encryption function that is fed back to the 
shift register in OFB, whereas in CFB, the ciphertext unit is fed back to the shift reg- 
ister. The other difference is that the OFB mode operates on full blocks of plaintext 
and ciphertext, not on an s-bit subset. Encryption can be expressed as 

Cj = P} ® E(K, [G-i © Pj-1)) 
By rearranging terms, we can demonstrate that decryption works. 


P; = G@E(K,[C-1 © Pj-1]) 


Nonce 


(a) Encryption 


(b) Decryption 
Figure 6.6 Output Feedback (OFB) Mode 
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We can define OFB mode as follows. 


I, = Nonce I, = Nonce 

T= Oi-1 j=2,...,N vf = LSB,-.(Jj-1) | Ci-1 j=2,...,N 
OFB O,=E(K,I) j=1,...,N O; = E(K, I) j=l...,N 

Cy = Py © MSB,(Oy) Py = Cy ® MSB,(Oy) 


Let the size of a block be b. If the last block of plaintext contains wu bits (indi- 
cated by *), with wu < b,the most significant u bits of the last output block Oy are used 
for the XOR operation; the remaining b—u bits of the last output block are discarded. 

As with CBC and CFB, the OFB mode requires an initialization vector. In the 
case of OFB, the IV must be a nonce; that is, the [V must be unique to each execu- 
tion of the encryption operation. The reason for this is that the sequence of encryp- 
tion output blocks, O;, depends only on the key and the IV and does not depend on 
the plaintext. Therefore, for a given key and IV, the stream of output bits used to 
XOR with the stream of plaintext bits is fixed. If two different messages had an 
identical block of plaintext in the identical position, then an attacker would be able 
to determine that portion of the O; stream. 

One advantage of the OFB method is that bit errors in transmission do not 
propagate. For example, if a bit error occurs in C,, only the recovered value of P, is 
affected; subsequent plaintext units are not corrupted. With CFB, C; also serves as 
input to the shift register and therefore causes additional corruption downstream. 

The disadvantage of OFB is that it is more vulnerable to a message stream 
modification attack than is CFB. Consider that complementing a bit in the cipher- 
text complements the corresponding bit in the recovered plaintext. Thus, controlled 
changes to the recovered plaintext can be made. This may make it possible for an 
opponent, by making the necessary changes to the checksum portion of the message 
as well as to the data portion, to alter the ciphertext in such a way that it is not 
detected by an error-correcting code. For a further discussion, see [VOYD83]. 

OFB has the structure of a typical stream cipher, because the cipher generates 
a stream of bits as a function of an initial value and a key, and that stream of bits is 
XORed with the plaintext bits (see Figure 3.1). The generated stream that is 
XORed with the plaintext is itself independent of the plaintext; this is highlighted 
by dashed boxes in Figure 6.6. One distinction from the stream ciphers we discuss in 
Chapter 7 is that OFB encrypts plaintext a full block at a time, where typically a 
block is 64 or 128 bits. Many stream ciphers encrypt one byte at a time. 


6.6 COUNTER MODE 


Although interest in the counter (CTR) mode has increased recently with applica- 
tions to ATM (asynchronous transfer mode) network security and IP sec (IP security), 
this mode was proposed early on (e.g., [DIFF79]). 

Figure 6.7 depicts the CTR mode. A counter equal to the plaintext block size is 
used. The only requirement stated in SP 800-38A is that the counter value must be 
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(a) Encryption 


(b) Decryption 
Figure 6.7 Counter (CTR) Mode 


different for each plaintext block that is encrypted. Typically, the counter is initialized 
to some value and then incremented by 1 for each subsequent block (modulo 2’, 
where b is the block size). For encryption, the counter is encrypted and then XORed 
with the plaintext block to produce the ciphertext block; there is no chaining. For 
decryption, the same sequence of counter values is used, with each encrypted counter 
XORed with a ciphertext block to recover the corresponding plaintext block. Thus, 
the initial counter value must be made available for decryption. Given a sequence of 
counters T;, T>, ..., Ty, we can define CTR mode as follows. 


CG =P,@E(K,T) j=1...,.N-1]P=G@EKT) j=1...,N-1 


CTR : : : 
Cy = Py @ MSB,[E(K, Ty)] Py = Cy © MSB,[E(K, Tw)] 
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For the last plaintext block, which may be a partial block of u bits, the most sig- 
nificant u bits of the last output block are used for the XOR operation; the remaining 
b—u bits are discarded. Unlike the ECB, CBC, and CFB modes, we do not need to 
use padding because of the structure of the CTR mode. 

As with the OFB mode, the initial counter value must be a nonce; that is, 7; 
must be different for all of the messages encrypted using the same key. Further, all 7; 
values across all messages must be unique. If, contrary to this requirement, a counter 
value is used multiple times, then the confidentiality of all of the plaintext blocks 
corresponding to that counter value may be compromised. In particular, if any plain- 
text block that is encrypted using a given counter value is known, then the output of 
the encryption function can be determined easily from the associated ciphertext 
block. This output allows any other plaintext blocks that are encrypted using the 
same counter value to be easily recovered from their associated ciphertext blocks. 

One way to ensure the uniqueness of counter values is to continue to incre- 
ment the counter value by 1 across messages. That is, the first counter value of the 
each message is one more than the last counter value of the preceding message. 

[LIPMO0] lists the following advantages of CTR mode. 


e Hardware efficiency: Unlike the three chaining modes, encryption (or 
decryption) in CTR mode can be done in parallel on multiple blocks of plain- 
text or ciphertext. For the chaining modes, the algorithm must complete the 
computation on one block before beginning on the next block. This limits the 
maximum throughput of the algorithm to the reciprocal of the time for one 
execution of block encryption or decryption. In CTR mode, the throughput is 
only limited by the amount of parallelism that is achieved. 


Software efficiency: Similarly, because of the opportunities for parallel execu- 
tion in CTR mode, processors that support parallel features, such as aggressive 
pipelining, multiple instruction dispatch per clock cycle, a large number of reg- 
isters, and SIMD instructions, can be effectively utilized. 


e Preprocessing: The execution of the underlying encryption algorithm does not 
depend on input of the plaintext or ciphertext. Therefore, if sufficient memory 
is available and security is maintained, preprocessing can be used to prepare 
the output of the encryption boxes that feed into the XOR functions, as in 
Figure 6.7. When the plaintext or ciphertext input is presented, then the only 
computation is a series of XORs. Such a strategy greatly enhances throughput. 


e Random access: The ith block of plaintext or ciphertext can be processed in 
random-access fashion. With the chaining modes, block C; cannot be com- 
puted until the i- 1 prior block are computed. There may be applications in 
which a ciphertext is stored and it is desired to decrypt just one block; for such 
applications, the random access feature is attractive. 


e Provable security: It can be shown that CTR is at least as secure as the other 
modes discussed in this section. 


Simplicity: Unlike ECB and CBC modes, CTR mode requires only the imple- 
mentation of the encryption algorithm and not the decryption algorithm. This 
matters most when the decryption algorithm differs substantially from the 
encryption algorithm, as it does for AES. In addition, the decryption key 
scheduling need not be implemented. 
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Note that, with the exception of ECB, all of the NIST-approved block cipher 
modes of operation involve feedback. This is clearly seen in Figure 6.8. To highlight 
the feedback mechanism, it is useful to think of the encryption function as taking 
input from a input register whose length equals the encryption block length and 
with output stored in an output register. The input register is updated one block at a 
time by the feedback mechanism. After each update, the encryption algorithm is 
executed, producing a result in the output register. Meanwhile, a block of plaintext 
is accessed. Note that both OFB and CTR produce output that is independent of 
both the plaintext and the ciphertext. Thus, they are natural candidates for stream 


ciphers that encrypt plaintext by XOR one full block at a time. 


Plaintext block 


Input register 


Key 


Encrypt 


Output register’ 


Ciphertext 


(a) Cipher block chaining (CBC) mode 
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Output register 
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(c) Output feedback (OFB) mode 
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(b) Cipher feedback (CFB) mode 
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Input register 


Encrypt 


Output register 


Ciphertext 


(d) Counter (CTR) mode 


Figure 6.8 Feedback Characteristic of Modes of Operation 
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6.7 XTS-AES MODE FOR BLOCK-ORIENTED 


STORAGE DEVICES 


NIST is currently in the process of approving an additional block cipher mode of 
operation, XTS-AES. This mode is also an IEEE standard, IEEE Std 1619-2007, 
which was developed by the IEEE Security in Storage Working Group (P1619). The 
standard describes a method of encryption for data stored in sector-based devices 
where the threat model includes possible access to stored data by the adversary. 
The XTS-AES mode is based on the concept of a tweakable block cipher, 
introduced in [LISK02]. The form of this concept used in XTS-AES was first 
described in [ROGA04]. The standard has received widespread industry support. 


Storage Encryption Requirements 


The requirements for encrypting stored data, also referred to as “data at rest” differ 
somewhat from those for transmitted data. The P1619 standard was designed to 
have the following characteristics: 


1. The ciphertext is freely available for an attacker. Among the circumstances 
that lead to this situation: 

a. A group of users has authorized access to a database. Some of the records 
in the database are encrypted so that only specific users can successfully 
read/write them. Other users can retrieve an encrypted record but are 
unable to read it without the key. 

b. An unauthorized user manages to gain access to encrypted records. 

c. A data disk or laptop is stolen, giving the adversary access to the encrypted 
data. 

. The data layout is not changed on the storage medium and in transit. The 
encrypted data must be the same size as the plaintext data. 


nN 


3. Data are accessed in fixed sized blocks, independently from each other. That is, an 
authorized user may access one or more blocks in any order. 


4. Encryption is performed in 16-byte blocks, independently from other blocks (except 
the last two plaintext blocks of a sector, if its size is not a multiple of 16 bytes). 


5. There are no other metadata used, except the location of the data blocks within 
the whole data set. 


6. The same plaintext is encrypted to different ciphertexts at different locations, but 
always to the same ciphertext when written to the same location again. 


7. A standard conformant device can be constructed for decryption of data 
encrypted by another standard conformant device. 


The P1619 group considered some of the existing modes of operation for use with 
stored data. For CTR mode, an adversary with write access to the encrypted media can 
flip any bit of the plaintext simply by flipping the corresponding ciphertext bit. 

Next, consider requirement 6 and the use of CBC. To enforce the requirement 
that the same plaintext encrypt to different ciphertext in different locations, the IV 
could be derived from the sector number. Each sector contains multiple blocks. An 
adversary with read/write access to the encrypted disk can copy a ciphertext sector 
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from one position to another, and an application reading the sector off the new loca- 
tion will still get the same plaintext sector (except perhaps the first 128 bits). For 
example, this means that an adversary that is allowed to read a sector from the sec- 
ond position but not the first can find the content of the sector in the first position 
by manipulating the ciphertext. Another weakness is that an adversary can flip any 
bit of the plaintext by flipping the corresponding ciphertext bit of the previous 
block, with the side-effect of “randomizing” the previous block. 


Operation on a Single Block 


Figure 6.9 shows the encryption and decryption of a single block. The operation 
involves two instances of the AES algorithm with two keys. The following parame- 
ters are associated with the algorithm. 


Key, 


AES 
Encrypt 


Key, 


Key, 


AES 
Encrypt 


AES 
Decrypt 


P. 


cc 
Key, 
P 


(b) Decryption 
Figure 6.9 XTS-AES Operation on Single Block 
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Key The 256 or 512 bit XTS-AES key; this is parsed as a concatenation of two 
fields of equal size called Key, and Key , such that Key = Key, || Key. 


P; The jth block of plaintext. All blocks except possibly the final block 
have a length of 128 bits. A plaintext data unit, typically a disk sector, 
consists of a sequence of plaintext blocks P;, Ps, ..., Py. 

C The jth block of ciphertext. All blocks except possibly the final block 
have a length of 128 bits. 

j The sequential number of the 128-bit block inside the data unit. 


The value of the 128-bit tweak. Each data unit (sector) is assigned a 
tweak value that is a nonnegative integer. The tweak values are 
assigned consecutively, starting from an arbitrary nonnegative integer. 
a A primitive element of GF(2'78) that corresponds to polynomial x 

(i.e., 0000... 0103). 
al a multiplied by itself j times, in GF(2!”*). 
@ _ Bitwise XOR. 
@® Modular multiplication of two polynomials with binary coefficients 
modulo x'78 + x7 + x? + x + 1.Thus, this is multiplication in GF(2"”’). 


~. 


In essence, the parameter j functions much like the counter in CTR mode. It 
assures that if the same plaintext block appears at two different positions within a 
data unit, it will encrypt to two different ciphertext blocks. The parameter i functions 
much like a nonce at the data unit level. It assures that, if the same plaintext block 
appears at the same position in two different data units, it will encrypt to two differ- 
ent ciphertext blocks. More generally, it assures that the same plaintext data unit will 
encrypt to two different ciphertext data units for two different data unit positions. 

The encryption and decryption of a single block can be described as 


T =E(K2,i) Qa! T =E(K>,i) @ad 
XTS-AES block | PP = P@T CC=C@T 
operation CC = E(K;, PP) PP = D(K;, CC) 
C =CC@T Po SPP OT 


To see that decryption recovers the plaintext, let us expand the last line of both 
encryption and decryption. For encryption, we have 


C= CC@T = E(k, PP) @T = E(k, POT) OT 
and for decryption, we have 
P= PP@T= D(ki,, CC) @T = D(k,, COT) OT 
Now, we substitute for C: 
P=D(Ki,CQ@T)@®T 
= D(K, [E(Ki, POT) ONO) OT 
= D(Ki, E(Ki, P® 1) @T 
=(P@N@®T=P 
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Operation on a Sector 


The plaintext of a sector or data unit is organized into blocks of 128 bits. Blocks are 
labeled Po, P,,..., P,,.The last block my be null or may contain from 1 to 127 bits. In 
other words, the input to the XTS-AES algorithm consists of m 128-bit blocks and 
possibly a final partial block. 

For encryption and decryption, each block is treated independently and 
encrypted/decrypted as shown in Figure 6.9. The only exception occurs when the last 
block has less than 128 bits. In that case, the last two blocks are encrypted/decrypted 
using a ciphertext-stealing technique instead of padding. Figure 6.10 shows the 
scheme. P,,,_; is the last full plaintext block, and P,,is the final plaintext block, which 
contains s bits with 1 = s = 127. C,,_, is the last full ciphertext block, and C,,,is the 
final ciphertext block, which contains s bits. 


XTS-AES XTS-AES XTS-AES XTS-AES 
block block block block 
encryption encryption encryption encryption 


XTS-AES XTS-AES XTS-AES XTS-AES 
block block block block 
decryption decryption decryption decryption 


(b) Decryption 
Figure 6.10 XTS-AES Mode 
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Let us label the block encryption and decryption algorithms of Figure 6.9 as 


Block encryption: XTS-AES-blockEnc(K, P;, i, j) 
Block decryption: XTS-AES-blockDec(K, C;, i, j) 


Then, if the final block is null, XTS-AES mode is defined as follows: 


XTS-AES mode with null ; = XTS-AES-blockEnc(K, P,,i,j) j =0,...,m—1 


final block P; 


= XTS-AES-blockEnc(K, Cj, i,j) j = 0,...,m—-1 


C; = XTS-AES-blockEnc(K, P,,i,j) j =0,...,m —2 
XX = XTS-AES-blockEnc(K, P,,-1, i,m — 1) 

CP = LSBis-,(XX) 

YY = P,, || CP 

Cn—1 = XTS-AES-blockEnc(K, YY, i, ™) 

Cn = MSB,(XX) 

P; = XTS-AES-blockDec(K, C;,i,j) j =0,...,m—2 
YY = XTS-AES-blockDec(K, C,,-1, i,m — 1) 

CP = LSBig-,(YY) 


XTS-AES mode with final 
block containing s bits 


XX = C,,|| CP 
P»—1 = XTS-AES-blockDec(K, XX, i, m) 
P,, = MSB,(YY) 


As can be seen, XTS-AES mode, like CTR mode, is suitable for parallel 
operation. Because there is no chaining, multiple blocks can be encrypted or 
decrypted simultaneously. Unlike CTR mode, XTS-AES mode includes a nonce 
(the parameter /) as well as a counter (parameter /). 


6.8 RECOMMENDED WEB SITE 


Ww 


Recommended Web Site: 


e Block cipher modes of operation: NIST page with full information on NIST- 
approved modes of operation. 


6.9 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


Block cipher modes of 
operation 
cipher block chaining 


mode (CBC) 
cipher feedback mode (CFB) 
ciphertext stealing 


counter mode (CTR) 
electronic codebook 

mode (ECB) 
meet-in-the-middle attack 
nonce 


output feedback 
mode (OFB) 

Triple DES (3DES) 

XTS-AES mode 
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Review Questions 


6.1 What is triple encryption? 
6.2 What is a meet-in-the-middle attack? 
6.3 How many keys are used in triple encryption? 
6.4 Why is the middle portion of 3DES a decryption rather than an encryption? 
6.5 Why do some block cipher modes of operation only use encryption while others use 
both encryption and decryption? 
Problems 
6.1 You want to build a hardware device to do block encryption in the cipher block 


chaining (CBC) mode using an algorithm stronger than DES. 3DES is a good can- 
didate. Figure 6.11 shows two possibilities, both of which follow from the definition 
of CBC. Which of the two would you choose: 

a. For security? 

b. For performance? 

Can you suggest a security improvement to either option in Figure 6.11, using only 
three DES chips and some number of XOR functions? Assume you are still limited to 
two keys. 


K,, Ky —>| EDE 


C, 


(b) One-loop CBC 


(b) Three-loop CBC 
Figure 6.11 Use of Triple DES in CBC Mode 
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6.3 


6.4 


6.7 


6.8 


6.9 


6.10 


6.11 


6.12 


The Merkle-Hellman attack on 3DES begins by assuming a value of A = 0 (Figure 
6.1b). Then, for each of the 2°° possible values of Kj, the plaintext P that produces 
A = Ois determined. Describe the rest of the algorithm. 

With the ECB mode, if there is an error in a block of the transmitted ciphertext, only 
the corresponding plaintext block is affected. However, in the CBC mode, this error 
propagates. For example, an error in the transmitted C, (Figure 6.4) obviously 
corrupts P; and P). 


a. Are any blocks beyond P) affected? 

b. Suppose that there is a bit error in the source version of P,. Through how 
many ciphertext blocks is this error propagated? What is the effect at the 
receiver? 


Is it possible to perform encryption operations in parallel on multiple blocks of plain- 
text in CBC mode? How about decryption? 

CBC-Pad is a block cipher mode of operation used in the RCS block cipher, but it 
could be used in any block cipher. CBC-Pad handles plaintext of any length. 
The ciphertext is longer then the plaintext by at most the size of a single block. 
Padding is used to assure that the plaintext input is a multiple of the block length. 
It is assumed that the original plaintext is an integer number of bytes. This plain- 
text is padded at the end by from 1 to bb bytes, where bb equals the block size 
in bytes. The pad bytes are all the same and set to a byte that represents the 
number of bytes of padding. For example, if there are 8 bytes of padding, each byte 
has the bit pattern 00001000. Why not allow zero bytes of padding? That is, if the 
original plaintext is an integer multiple of the block size, why not refrain from 
padding? 

For the ECB, CBC, and CFB modes, the plaintext must be a sequence of one or 
more complete data blocks (or, for CFB mode, data segments). In other words, for 
these three modes, the total number of bits in the plaintext must be a positive 
multiple of the block (or segment) size. One common method of padding, if 
needed, consists of a 1 bit followed by as few zero bits, possibly none, as are nec- 
essary to complete the final block. It is considered good practice for the sender to 
pad every message, including messages in which the final message block is already 
complete. What is the motivation for including a padding block when padding is 
not needed? 

If a bit error occurs in the transmission of a ciphertext character in 8-bit CFB mode, 
how far does the error propagate? 

In discussing OFB, it was mentioned that if it was known that two different messages 
had an identical block of plaintext in the identical position, it is possible to recover the 
corresponding O; block. Show the calculation. 

In discussing the CTR mode, it was mentioned that if any plaintext block that 
is encrypted using a given counter value is known, then the output of the encryption 
function can be determined easily from the associated ciphertext block. Show the 
calculation. 

Padding may not always be appropriate. For example, one might wish to store the 
encrypted data in the same memory buffer that originally contained the plaintext. In 
that case, the ciphertext must be the same length as the original plaintext. A mode for 
that purpose is the ciphertext stealing (CTS) mode. Figure 6.12a shows an implemen- 
tation of this mode. 


a. Explain how it works. 

b. Describe how to decrypt C,,; and C,,. 

Figure 6.12b shows an alternative to CTS for producing ciphertext of equal length to 
the plaintext when the plaintext is not an integer multiple of the block size. 


a. Explain the algorithm. 
b. Explain why CTS is preferable to this approach illustrated in Figure 6.12b. 
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Py-\ Py | 00...0 | 


Cy x Cy-1 


cq 
(a) Ciphertext stealing mode 
Py Py-2 Py-\ P. N 
Iv __ (bb bits) (bb bits) (bb bits) (j bits) 


select 
leftmost 


CQ Cy-2 Cy-1 Cy 
(bb bits) (bb bits) (bb bits) (j bits) 


(b) Alternative method 
Figure 6.12 Block Cipher Modes for Plaintext not a Multiple of Block Size 


Programming Problems 


6.13 Create software that can encrypt and decrypt in cipher block chaining mode using one 
of the following ciphers: affine modulo 256, Hill modulo 256, S-DES, DES. 
Test data for S-DES using a binary initialization vector of 1010 1010. A binary plain- 
text of 0000 0001 0010 0011 encrypted with a binary key of 01111 11101 should give a 
binary plaintext of 1111 0100 0000 1011. Decryption should work correspondingly. 
6.14 Create software that can encrypt and decrypt in 4-bit cipher feedback mode using one 
of the following ciphers: additive modulo 256, affine modulo 256, S-DES; 
or 
8-bit cipher feedback mode using one of the following ciphers: 2 x 2 Hill modulo 256. 
Test data for S-DES using a binary initialization vector of 1010 1011. A binary plain- 
text of 0001 0010 0011 0100 encrypted with a binary key of 01111 11101 should give a 
binary plaintext of 1110 1100 1111 1010. Decryption should work correspondingly. 
6.15 Create software that can encrypt and decrypt in counter mode using one of the fol- 
lowing ciphers: affine modulo 256, Hill modulo 256, S-DES. 
Test data for S-DES using a counter starting at 0000 0000. A binary plaintext of 0000 0001 
0000 0010 0000 0100 encrypted with a binary key of 01111 11101 should give a binary 
plaintext of 0011 1000 0100 1111 0011 0010. Decryption should work correspondingly. 
6.16 Implement a differential cryptanalysis attack on 3-round S-DES. 
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The comparatively late rise of the theory of probability shows how hard it is to 
grasp, and the many paradoxes show clearly that we, as humans, lack a well 
grounded intuition in this matter. 

In probability theory there is a great deal of art in setting up the model, in solving 
the problem, and in applying the results back to the real world actions that will follow. 


—The Art of Probability, Richard Hamming 


KEY POINTS 


® A capability with application to a number of cryptographic functions is 
random or pseudorandom number generation. The principle requirement 
for this capability is that the generated number stream be unpredictable. 


® A stream cipher is a symmetric encryption algorithm in which ciphertext 
output is produced bit-by-bit or byte-by-byte from a stream of plaintext 
input. The most widely used such cipher is RC4. 


An important cryptographic function is cryptographically strong pseudorandom num- 
ber generation. Pseudorandom number generators (PRNGs) are used in a variety of 
cryptographic and security applications. We begin the chapter with a look at the basic 
principles of PRNGs and contrast these with true random number generators 
(TRNGs).! Next, we look at some common PRNGs, including PRNGs based on the 
use of a symmetric block cipher. 

The chapter then moves on to the topic of symmetric stream ciphers, which are 
based on the use of a PRNG. The chapter next examines the most important stream 
cipher, RC4. Finally, we examine TRNGs. 


7.1. PRINCIPLES OF PPEUDORANDOM NUMBER GENERATION 


Random numbers play an important role in the use of encryption for various net- 
work security applications. In this section, we provide a brief overview of the use of 
random numbers in cryptography and network security and then focus on the prin- 
ciples of pseudorandom number generation. 


The Use of Random Numbers 


A number of network security algorithms and protocols based on cryptography 
make use of random binary numbers. For example, 


'A note on terminology. Some standards documents, notably NIST and ANSI, refer to a TRNG as a 
nondeterministic random number generator (NRNG) and a PRNG as a deterministic random number 
generator (DRNG). 
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e Key distribution and reciprocal authentication schemes, such as those discussed 
in Chapters 14 and 15. In such schemes, two communicating parties cooperate 
by exchanging messages to distribute keys and/or authenticate each other. In 
many cases, nonces are used for handshaking to prevent replay attacks. The use 
of random numbers for the nonces frustrates an opponent’s efforts to deter- 
mine or guess the nonce. 


e Session key generation. We will see a number of protocols in this book where 
a secret key for symmetric encryption is generated for use for a short period of 
time. This key is generally called a session key. 


e Generation of keys for the RSA public-key encryption algorithm (described 
in Chapter 9). 


e Generation of a bit stream for symmetric stream encryption (described in this 
chapter). 


These applications give rise to two distinct and not necessarily compatible 
requirements for a sequence of random numbers: randomness and unpredictability. 


RANDOMNESS Traditionally, the concern in the generation of a sequence of allegedly 
random numbers has been that the sequence of numbers be random in some well- 
defined statistical sense. The following two criteria are used to validate that a 
sequence of numbers is random: 


¢ Uniform distribution: The distribution of bits in the sequence should be 
uniform; that is, the frequency of occurrence of ones and zeros should be 
approximately equal. 


e Independence: No one subsequence in the sequence can be inferred from the 
others. 


Although there are well-defined tests for determining that a sequence of bits 
matches a particular distribution, such as the uniform distribution, there is no such 
test to “prove” independence. Rather, a number of tests can be applied to demon- 
strate if a sequence does not exhibit independence. The general strategy is to apply 
a number of such tests until the confidence that independence exists is sufficiently 
strong. 

In the context of our discussion, the use of a sequence of numbers that appear 
statistically random often occurs in the design of algorithms related to cryptography. 
For example, a fundamental requirement of the RSA public-key encryption scheme 
discussed in Chapter 9 is the ability to generate prime numbers. In general, it is dif- 
ficult to determine if a given large number N is prime. A brute-force approach 
would be to divide N by every odd integer less than VN. If N is on the order, say, of 
10°, which is a not uncommon occurrence in public-key cryptography, such a 
brute-force approach is beyond the reach of human analysts and their computers. 
However, a number of effective algorithms exist that test the primality of a number 
by using a sequence of randomly chosen integers as input to relatively simple 
computations. If the sequence is sufficiently long (but far, far less than V/10'*), the 
primality of a number can be determined with near certainty. This type of approach, 
known as randomization, crops up frequently in the design of algorithms. In essence, 
if a problem is too hard or time-consuming to solve exactly, a simpler, shorter 
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approach based on randomization is used to provide an answer with any desired 
level of confidence. 


UnpREDICTABILITY In applications such as reciprocal authentication, session key 
generation, and stream ciphers, the requirement is not just that the sequence of 
numbers be statistically random but that the successive members of the sequence 
are unpredictable. With “true” random sequences, each number is statistically 
independent of other numbers in the sequence and therefore unpredictable. 
However, as is discussed shortly, true random numbers are seldom used; rather, 
sequences of numbers that appear to be random are generated by some algorithm. 
In this latter case, care must be taken that an opponent not be able to predict future 
elements of the sequence on the basis of earlier elements. 


TRNGs, PRNGs, and PRFs 


Cryptographic applications typically make use of algorithmic techniques for ran- 
dom number generation. These algorithms are deterministic and therefore produce 
sequences of numbers that are not statistically random. However, if the algorithm is 
good, the resulting sequences will pass many reasonable tests of randomness. Such 
numbers are referred to as pseudorandom numbers. 

You may be somewhat uneasy about the concept of using numbers generated 
by a deterministic algorithm as if they were random numbers. Despite what might 
be called philosophical objections to such a practice, it generally works. As one 
expert on probability theory puts it [HAMM91]: 


For practical purposes we are forced to accept the awkward concept 
of “relatively random” meaning that with regard to the proposed 
use we can see no reason why they will not perform as if they were 
random (as the theory usually requires). This is highly subjective 
and is not very palatable to purists, but it is what statisticians regu- 
larly appeal to when they take “a random sample” —they hope that 
any results they use will have approximately the same properties as 
a complete counting of the whole sample space that occurs in their 
theory. 


Figure 7.1 contrasts a true random number generator (TRNG) with two forms 
of pseudorandom number generators. A TRNG takes as input a source that is effec- 
tively random; the source is often referred to as an entropy source. We discuss such 
sources in Section 7.6. In essence, the entropy source is drawn from the physical 
environment of the computer and could include things such as keystroke timing 
patterns, disk electrical activity, mouse movements, and instantaneous values of the 
system clock. The source, or combination of sources, serve as input to an algorithm 
that produces random binary output. The TRNG may simply involve conversion of 
an analog source to a binary output. The TRNG may involve additional processing 
to overcome any bias in the source; this is discussed in Section 7.6. 

In contrast, a PRNG takes as input a fixed value, called the seed, and produces 
a sequence of output bits using a deterministic algorithm. Typically, as shown, there 
is some feedback path by which some of the results of the algorithm are fed back as 
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Source of Context- 
true specific 
randomness Seed Seed values 


Conversion Deterministic Deterministic 


to binary algorithm algorithm 


Random Pseudorandom Pseudorandom 
bit stream bit stream value 
(a) TRNG (b) PRNG (c) PRF 


TRNG = true random number generator 
PRNG = pseudorandom number generator 
PRF = pseudorandom function 


Figure 7.1 Random and Pseudorandom Number Generators 


input as additional output bits are produced. The important thing to note is that the 

output bit stream is determined solely by the input value or values, so that an adver- 

sary who knows the algorithm and the seed can reproduce the entire bit stream. 
Figure 7.1 shows two different forms of PRNGs, based on application. 


e Pseudorandom number generator: An algorithm that is used to produce an 
open-ended sequence of bits is referred to as a PRNG. A common application 
for an open-ended sequence of bits is as input to a symmetric stream cipher, as 
discussed in Section 7.4. Also, see Figure 3.1a. 


e Pseudorandom function (PRF): A PRF is used to produced a pseudorandom 
string of bits of some fixed length. Examples are symmetric encryption keys 
and nonces. Typically, the PRF takes as input a seed plus some context specific 
values, such as a user ID or an application ID. A number of examples of PRFs 
will be seen throughout this book, notably in Chapters 16 and 17. 


Other than the number of bits produced, there is no difference between a 
PRNG and a PRF. The same algorithms can be used in both applications. Both 
require a seed and both must exhibit randomness and unpredictability. Further, a 
PRNG application may also employ context-specific input. In what follows, we 
make no distinction between these two applications. 


PRNG Requirements 


When a PRNG or PREF is used for a cryptographic application, then the basic 
requirement is that an adversary who does not know the seed is unable to deter- 
mine the pseudorandom string. For example, if the pseudorandom bit stream is 
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used in a stream cipher, then knowledge of the pseudorandom bit stream would 
enable the adversary to recover the plaintext from the ciphertext. Similarly, we 
wish to protect the output value of a PRE In this latter case, consider the following 
scenario. A 128-bit seed, together with some context-specific values, are used to 
generate a 128-bit secret key that is subsequently used for symmetric encryption. 
Under normal circumstances, a 128-bit key is safe from a brute-force attack. 
However, if the PRF does not generate effectively random 128-bit output values, it 
may be possible for an adversary to narrow the possibilities and successfully use a 
brute force attack. 

This general requirement for secrecy of the output of a PRNG or PRF leads to 
specific requirements in the areas of randomness, unpredictability, and the character- 
istics of the seed. We now look at these in turn. 


RANDOMNESS In terms of randomness, the requirement for a PRNG is that the 
generated bit stream appear random even though it is deterministic. There is no 
single test that can determine if a PRNG generates numbers that have the 
characteristic of randomness. The best that can be done is to apply a sequence of 
tests to the PRNG. If the PRNG exhibits randomness on the basis of multiple tests, 
then it can be assumed to satisfy the randomness requirement. NIST SP 800-22 
(A Statistical Test Suite for Random and Pseudorandom Number Generators for 
Cryptographic Applications) specifies that the tests should seek to establish the 
following three characteristics. 


e Uniformity: At any point in the generation of a sequence of random or 
pseudorandom bits, the occurrence of a zero or one is equally likely, i.e., the 
probability of each is exactly 1/2. The expected number of zeros (or ones) is 
n/2, where n = the sequence length. 


e Scalability: Any test applicable to a sequence can also be applied to subse- 
quences extracted at random. If a sequence is random, then any such extracted 
subsequence should also be random. Hence, any extracted subsequence 
should pass any test for randomness. 


e Consistency: The behavior of a generator must be consistent across starting 
values (seeds). It is inadequate to test a PRNG based on the output from a sin- 
gle seed or an TRNG on the basis of an output produced from a single physi- 
cal output 


SP 800-22 lists 15 separate tests of randomness. An understanding of these 
tests requires a basic knowledge of statistical analysis, so we don’t attempt a techni- 
cal description here. Instead, to give some flavor for the tests, we list three of the 
tests and the purpose of each test, as follows. 


e Frequency test: This is the most basic test and must be included in any test 
suite. The purpose of this test is to determine whether the number of ones and 
zeros in a sequence is approximately the same as would be expected for a truly 
random sequence. 


e Runs test: The focus of this test is the total number of runs in the sequence, 
where a run is an uninterrupted sequence of identical bits bounded before and 
after with a bit of the opposite value. The purpose of the runs test is to determine 
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whether the number of runs of ones and zeros of various lengths is as expected 
for a random sequence. 


e Maurer’s universal statistical test: The focus of this test is the number of bits 
between matching patterns (a measure that is related to the length of a com- 
pressed sequence). The purpose of the test is to detect whether or not the 
sequence can be significantly compressed without loss of information. A signifi- 
cantly compressible sequence is considered to be non-random. 


UnprepicTaBiLity A stream of pseudorandom numbers should exhibit two forms 
of unpredictability: 


e Forward unpredictability: If the seed is unknown, the next output bit in the 
sequence should be unpredictable in spite of any knowledge of previous bits in 
the sequence. 


e Backward unpredictability: It should also not be feasible to determine the 
seed from knowledge of any generated values. No correlation between a seed 
and any value generated from that seed should be evident; each element of the 
sequence should appear to be the outcome of an independent random event 
whose probability is 1/2. 


The same set of tests for randomness also provide a test of unpredictability. If 
the generated bit stream appears random, then it is not possible to predict some bit 
or bit sequence from knowledge of any previous bits. Similarly, if the bit sequence 
appears random, then there is no feasible way to deduce the seed based on the bit 
sequence. That is, a random sequence will have no correlation with a fixed value 
(the seed). 


SEED REQUIREMENTS For cryptographic applications, the seed that serves as input to 
the PRNG must be secure. Because the PRNG is a deterministic algorithm, if the 
adversary can deduce the seed, then the output can also be determined. Therefore, 
the seed must be unpredictable. In fact, the seed itself must be a random or 
pseudorandom number. 

Typically, the seed is generated by a TRNG, as shown in Figure 7.2. This is 
the scheme recommended by SP800-90. The reader may wonder, if a TRNG is 
available, why it is necessary to use a PRNG. If the application is a stream cipher, 
then a TRNG is not practical. The sender would need to generate a keystream of 
bits as long as the plaintext and then transmit the keystream and the ciphertext 
securely to the receiver. If a PRNG is used, the sender need only find a way to 
deliver the stream cipher key, which is typically 54 or 128 bits, to the receiver ina 
secure fashion. 

Even in the case of a PRF application, in which only a limited number of bits is 
generated, it is generally desirable to use a TRNG to provide the seed to the PRF 
and use the PRF output rather then use the TRNG directly. As is explained in a 
Section 7.6, a TRNG may produce a binary string with some bias. The PRF would 
have the effect of “randomizing” the output of the TRNG so as to eliminate that bias. 

Finally, the mechanism used to generate true random numbers may not be 
able to generate bits at a rate sufficient to keep up with the application requiring the 
random bits. 
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Figure 7.2 Generation of Seed Input to PRNG 


Algorithm Design 


Cryptographic PRNGs have been the subject of much research over the years, 
and a wide variety of algorithms have been developed. These fall roughly into 
two categories. 


e Purpose-built algorithms: These are algorithms designed specifically and solely 
for the purpose of generating pseudorandom bit streams. Some of these algo- 
rithms are used for a variety of PRNG applications; several of these are described 
in the next section. Others are designed specifically for use in a stream cipher. 
The most important example of the latter is RC4, described in Section 7.5. 


e Algorithms based on existing cryptographic algorithms: Cryptographic algo- 
rithms have the effect of randomizing input. Indeed, this is a requirement of 
such algorithms. For example, if a symmetric block cipher produced ciphertext 
that had certain regular patterns in it, it would aid in the process of cryptanalysis. 
Thus, cryptographic algorithms can serve as the core of PRNGs. Three broad 
categories of cryptographic algorithms are commonly used to create PRNGs: 


—Symmetric block ciphers: This approach is discussed in Section 7.3. 


—Asymmetric ciphers: The number theoretic concepts used for an asymmetric 
cipher can also be adapted for a PRNG; this approach is examined in Chapter 10. 


—Hash functions and message authentication codes: This approach is examined 
in Chapter 12. 


Any of these approaches can yield a cryptographically strong PRNG. A 
purpose-built algorithm may be provided by an operating system for general use. 
For applications that already use certain cryptographic algorithms for encryption or 
authentication, it makes sense to reuse the same code for the PRNG. Thus, all of 
these approaches are in common use. 
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7.2 PSEUDORANDOM NUMBER GENERATORS 


In this section, we look at two types of algorithms for PRNGs. 


Linear Congruential Generators 


A widely used technique for pseudorandom number generation is an algorithm first 
proposed by Lehmer [LEHMS1], which is known as the linear congruential method. 
The algorithm is parameterized with four numbers, as follows: 


m the modulus m>0 
a the multiplier O<a<m 
c the increment O=c<m 
Xo the starting value, or seed 0s X)<m 
The sequence of random numbers {X’,} is obtained via the following iterative 
equation: 


Xn+1 = (aX, + c)mod m 


If m,a,c,and X,are integers, then this technique will produce a sequence of integers 
with each integer in the range 0 = X, < m. 

The selection of values for a, c, and m is critical in developing a good random 
number generator. For example, consider a = c = 1. The sequence produced is 
obviously not satisfactory. Now consider the values a= 7, c = 0, m = 32, 
and X) = 1. This generates the sequence {7, 17, 23,1,7, etc.}, which is also 
clearly unsatisfactory. Of the 32 possible values, only four are used; thus, the 
sequence is said to have a period of 4. If, instead, we change the value of a to 5, 
then the sequence is {5, 25, 29,17, 21,9, 13,1,5,etc.}, which increases the 
period to 8. 

We would like m to be very large, so that there is the potential for producing a 
long series of distinct random numbers. A common criterion is that m be nearly 
equal to the maximum representable nonnegative integer for a given computer. 
Thus, a value of m near to or equal to 2*! is typically chosen. 

[PARK88a] proposes three tests to be used in evaluating a random number 
generator: 


T,: The function should be a full-period generating function. That is, the 
function should generate all the numbers between 0 and m before repeating. 

Tz: The generated sequence should appear random. 

T3: The function should implement efficiently with 32-bit arithmetic. 


With appropriate values of a,c, and m, these three tests can be passed. With 
respect to T;, it can be shown that if m is prime and c = 0, then for certain values of 
a the period of the generating function is m — 1, with only the value 0 missing. For 
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32-bit arithmetic, a convenient prime value of m is 2°! — 1. Thus, the generating 
function becomes 


Xn+1 = (aX,,) mod a ~ 1) 


Of the more than 2 billion possible choices for a, only a handful of multipliers 
pass all three tests. One such value is a = 7° = 16807, which was originally selected 
for use in the IBM 360 family of computers [LEWI69]. This generator is widely used 
and has been subjected to a more thorough testing than any other PRNG. It is 
frequently recommended for statistical and simulation work (e.g., [JAIN91]). 

The strength of the linear congruential algorithm is that if the multiplier and 
modulus are properly chosen, the resulting sequence of numbers will be statistically 
indistinguishable from a sequence drawn at random (but without replacement) 
from the set 1, 2,...,m — 1. But there is nothing random at all about the algorithm, 
apart from the choice of the initial value Xo. Once that value is chosen, the remain- 
ing numbers in the sequence follow deterministically. This has implications for 
cryptanalysis. 

If an opponent knows that the linear congruential algorithm is being used 
and if the parameters are known (e.g., a = 7°, c = 0, m = 2°! — 1), then once a 
single number is discovered, all subsequent numbers are known. Even if the oppo- 
nent knows only that a linear congruential algorithm is being used, knowledge of 
a small part of the sequence is sufficient to determine the parameters of the algo- 
rithm. Suppose that the opponent is able to determine values for Xo, X;, X2, and 
X3. Then 


X, = (aXo + c)modm 
X, = (aX, + c)modm 
X3 = (aX, + c)modm 


These equations can be solved for a, c, and m. 

Thus, although it is nice to be able to use a good PRNG, it is desirable to make 
the actual sequence used nonreproducible, so that knowledge of part of the sequence 
on the part of an opponent is insufficient to determine future elements of the 
sequence. This goal can be achieved in a number of ways. For example, [BRIG79] 
suggests using an internal system clock to modify the random number stream. One 
way to use the clock would be to restart the sequence after every N numbers using 
the current clock value (mod m) as the new seed. Another way would be simply to 
add the current clock value to each random number (mod m). 


Blum Blum Shub Generator 


A popular approach to generating secure pseudorandom numbers is known as the 
Blum, Blum, Shub (BBS) generator, named for its developers [BLUM86]. It has 
perhaps the strongest public proof of its cryptographic strength of any purpose-built 
algorithm. The procedure is as follows. First, choose two large prime numbers, p and 
q, that both have a remainder of 3 when divided by 4. That is, 


PD = q = 3(mod 4) 
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This notation, explained more fully in Chapter 4, simply means that 
(p mod 4) = (q mod 4) = 3. For example, the prime numbers 7 and 11 satisfy 
7 = 11 = 3(mod 4). Letn = p X q. Next, choose a random number s, such that s is 
relatively prime to n; this is equivalent to saying that neither p nor gq is a factor of s. 
Then the BBS generator produces a sequence of bits B; according to the following 
algorithm: 


Xo = s* mod n 
fori = 1 to © 
x = (%.4)* mod x 
Bj = X; mod 2 


Thus, the least significant bit is taken at each iteration. Table 7.1, shows an example 
of BBS operation. Here, n = 192649 = 383 x 503, and the seed s = 101355. 

The BBS is referred to as a cryptographically secure pseudorandom bit 
generator (CSPRBG). A CSPRBG is defined as one that passes the next-bit test, 
which, in turn, is defined as follows [MENE97]: A pseudorandom bit generator is 
said to pass the next-bit test if there is not a polynomial-time algorithm” that, on 
input of the first k bits of an output sequence, can predict the (kK + 1)st bit with 
probability significantly greater than 1/2. In other words, given the first k bits of the 
sequence, there is not a practical algorithm that can even allow you to state that the 
next bit will be 1 (or 0) with probability greater than 1/2. For all practical purposes, 
the sequence is unpredictable. The security of BBS is based on the difficulty of 
factoring n. That is, given n, we need to determine its two prime factors p and q. 


Table 7.1 Example Operation of BBS Generator 
xX, 
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2A polynomial-time algorithm of order k is one whose running time is bounded by a polynomial of 
order k. 
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7.3 > PSEUDORANDOM NUMBER GENERATION USING 
A BLOCK CIPHER 


A popular approach to PRNG construction is to use a symmetric block cipher as the 
heart of the PRNG mechanism. For any block of plaintext, a symmetric block cipher 
produces an output block that is apparently random. That is, there are no patterns or 
regularities in the ciphertext that provide information that can be used to deduce 
the plaintext. Thus, a symmetric block cipher is a good candidate for building a 
pseudorandom number generator. 

If an established, standardized block cipher is used, such as DES or AES, then 
the security characteristics of the PRNG can be established. Further, many applica- 
tions already make use of DES or AES, so the inclusion of the block cipher as part 
of the PRNG algorithm is straightforward. 


PRNG Using Block Cipher Modes of Operation 


Two approaches that use a block cipher to build a PNRG have gained widespread 
acceptance: the CTR mode and the OFB mode. The CTR mode is recommended in 
SP 800-90, in the ANSI standard X9.82 (Random Number Generation), and in RFC 
4086. The OFB mode is recommended in X9.82 and RFC 4086. 

Figure 7.3 illustrates the two methods. In each case, the seed consists of two 
parts: the encryption key value and a value V that will be updated after each block 
of pseudorandom numbers is generated. Thus, for AES-128, the seed consists of a 
128-bit key and a 128-bit V value. In the CTR case, the value of V is incremented 
by 1 after each encryption. In the case of OFB, the value of V is updated to equal 
the value of the preceding PRNG block. In both cases, pseudorandom bits are 
produced one block at a time (e.g., for AES, PRNG bits are generated 128 bits at 
a time). 


Encrypt 


Pseudorandom bits Pseudorandom bits 


(a) CTR mode (b) OFB mode 
Figure 7.3. PRNG Mechanisms Based on Block Ciphers 
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The CTR algorithm for PRNG can be summarized as follows. 


while (len (temp) < requested_number_of_bits) do 
V = (V+ 1) mod 2778, 
output_block = E(Key, V) 
temp = temp || ouput_block 


The OFB algorithm can be summarized as follows. 


while (len (temp) < requested_number_of_bits) do 
V = E(Key, V) 
temp = temp || V 


To get some idea of the performance of these two PRNGs, consider the fol- 
lowing short experiment. A random bit sequence of 256 bits was obtained from 
random.org, which uses three radios tuned between stations to pick up atmospheric 
noise. These 256 bits form the seed, allocated as 


c£b0ef3108d49cc4562d5810b0a9a£60 


4c89a£496176b728ed1e2ea8ba27£5a4 


The total number of one bits in the 256-bit seed is 124, or a fraction of 0.48, 
which is reassuringly close to the ideal of 0.5. 

For the OFB PRNG, Table 7.2 shows the first eight output blocks (1024 bits) 
with two rough measures of security. The second column shows the fraction of one 
bits in each 128-bit block. This corresponds to one of the NIST tests. The results indi- 
cate that the output is split roughly equally between zero and one bits. The third 
column shows the fraction of bits that match between adjacent blocks. If this num- 
ber differs substantially from 0.5, that suggests a correlation between blocks, which 
could be a security weakness. The results suggest no correlation. 


Table 7.2 Example Results for PRNG Using OFB 


Fraction of Bits that 
Fraction of One Match with 
Output Block Bits Preceding Block 


1786£4c7££6e291dbdfdd90ec3453176 0.57 


5e17b22b14677a4d66890£87565eae64 0.51 


£d18284ac82251dfb3aa62c326cd46cc 0.47 


c8e545198a758ef5dd86b41946389bd5 0.50 


fe7bae0e23019542962e2c52d215a2e3 0.47 


14f£d£5ec99469598ae0379472803accd 0.49 


6aeca972e5a3ef17bd1a1b775£c8b929 0.57 


£7e97bad£359d128£00d9b4ae323db64 0.55 
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Table 7.3 Example Results for PRNG Using CTR 


Fraction of Bits that 
Fraction of One Match with 
Output Block Bits Preceding Block 


1786£4c7££6e291dbdfdd90ec3453176 0.57 


60809669a3e092a01b463472fdcae420 0.41 


d4e6e170b46b057 3eed£88ee3 9bfF£33d 0.59 


5£8fcfc5decal8ea246785d7£adc76£8 0.59 
90e63ed27bb07 868c753545bdd57ee28 


0125856fd£4a17£747c7833695c52235 


£4be2d179b0£2548£d748c8£c7c81990 


1151f£c48£90eebac658a3911515c3c66 


Table 7.3 shows the results using the same key and V values for CTR mode. 
Again, the results are favorable. 


ANSI X9.17 PRNG 


One of the strongest (cryptographically speaking) PRNGs is specified in ANSI 
X9.17.A number of applications employ this technique, including financial security 
applications and PGP (the latter described in Chapter 18). 

Figure 7.4 illustrates the algorithm, which makes use of triple DES for 
encryption. The ingredients are as follows. 


e Input: Two pseudorandom inputs drive the generator. One is a 64-bit repre- 
sentation of the current date and time, which is updated on each number 
generation. The other is a 64-bit seed value; this is initialized to some arbitrary 
value and is updated during the generation process. 


Ky, Ko 


Viet 


Figure 7.4 ANSI X9.17 Pseudorandom Number Generator 
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e Keys: The generator makes use of three triple DES encryption modules. All 
three make use of the same pair of 56-bit keys, which must be kept secret and 
are used only for pseudorandom number generation. 


e Output: The output consists of a 64-bit pseudorandom number and a 64-bit 
seed value. 


Let us define the following quantities. 


DT; Date/time value at the beginning of ith generation stage 
V; Seed value at the beginning of ith generation stage 
R; Pseudorandom number produced by the ith generation stage 
Ky, K> DES keys used for each stage 
Then 


R; = EDE([K,, K3],[V; ® EDE([Kj, Ky], DT;)]) 
Vi+1 = EDE([Ki, Ko], [R; ® EDE([Ki, Kz], DT;))) 


where EDE([K;, K2],X) refers to the sequence encrypt-decrypt-encrypt using two- 
key triple DES to encrypt X. 

Several factors contribute to the cryptographic strength of this method. The 
technique involves a 112-bit key and three EDE encryptions for a total of nine DES 
encryptions. The scheme is driven by two pseudorandom inputs, the date and time 
value, and a seed produced by the generator that is distinct from the pseudorandom 
number produced by the generator. Thus, the amount of material that must be com- 
promised by an opponent is overwhelming. Even if a pseudorandom number R; 
were compromised, it would be impossible to deduce the V;,, from the R;, because 
an additional EDE operation is used to produce the Vj. 


7.4. STREAM CIPHERS 


A typical stream cipher encrypts plaintext one byte at a time, although a stream 
cipher may be designed to operate on one bit at a time or on units larger than a byte 
at a time. Figure 7.5 is a representative diagram of stream cipher structure. In this 
structure, a key is input to a pseudorandom bit generator that produces a stream of 
8-bit numbers that are apparently random. The output of the generator, called a 
keystream, is combined one byte at a time with the plaintext stream using the bit- 
wise exclusive-OR (XOR) operation. For example, if the next byte generated by the 
generator is 01101100 and the next plaintext byte is 11001100, then the resulting 
ciphertext byte is 


11001100 plaintext 
@ 01101100 key stream 
10100000 ciphertext 
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Key Key 
K K 
Pseudorandom byte Pseudorandom byte 
generator generator 
(key stream generator) (key stream generator) 
k k 
Plaintext Ciphertext Plaintext 
byte stream byte stream byte stream 
M ENCRYPTION Cc DECRYPTION M 


Figure 7.5 Stream Cipher Diagram 


Decryption requires the use of the same pseudorandom sequence: 


0100000 ciphertext 
@ 01101100 key stream 
001100 plaintext 


The stream cipher is similar to the one-time pad discussed in Chapter 2. The 
difference is that a one-time pad uses a genuine random number stream, whereas a 
stream cipher uses a pseudorandom number stream. 

[KUMA97] lists the following important design considerations for a stream 
cipher. 


1. The encryption sequence should have a large period. A pseudorandom num- 
ber generator uses a function that produces a deterministic stream of bits that 
eventually repeats. The longer the period of repeat the more difficult it will be 
to do cryptanalysis. This is essentially the same consideration that was 
discussed with reference to the Vigenére cipher, namely that the longer the 
keyword the more difficult the cryptanalysis. 


N 


. The keystream should approximate the properties of a true random number 
stream as close as possible. For example, there should be an approximately equal 
number of 1s and Os. If the keystream is treated as a stream of bytes, then all of 
the 256 possible byte values should appear approximately equally often. The 
more random-appearing the keystream is, the more randomized the ciphertext is, 
making cryptanalysis more difficult. 


Ge 


. Note from Figure 7.5 that the output of the pseudorandom number generator 
is conditioned on the value of the input key. To guard against brute-force 
attacks, the key needs to be sufficiently long. The same considerations that 
apply to block ciphers are valid here. Thus, with current technology, a key 
length of at least 128 bits is desirable. 
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Table 7.4 Speed Comparisons of Symmetric Ciphers on a Pentium IT 
Key Length Speed (Mbps) 
56 


168 


Variable 


Variable 


With a properly designed pseudorandom number generator, a stream cipher 
can be as secure as a block cipher of comparable key length. A potential advantage 
of a stream cipher is that stream ciphers that do not use block ciphers as a building 
block are typically faster and use far less code than do block ciphers. The example in 
this chapter, RC4, can be implemented in just a few lines of code. Table 7.4, using 
data from [RESCO01], compares execution times of RC4 with three symmetric block 
ciphers. One advantage of a block cipher is that you can reuse keys. In contrast, if 
two plaintexts are encrypted with the same key using a stream cipher, then crypt- 
analysis is often quite simple [DAWS96]. If the two ciphertext streams are XORed 
together, the result is the XOR of the original plaintexts. If the plaintexts are text 
strings, credit card numbers, or other byte streams with known properties, then 
cryptanalysis may be successful. 

For applications that require encryption/decryption of a stream of data, such 
as over a data communications channel or a browser/Web link, a stream cipher 
might be the better alternative. For applications that deal with blocks of data, such 
as file transfer, e-mail, and database, block ciphers may be more appropriate. 
However, either type of cipher can be used in virtually any application. 

A stream cipher can be constructed with any cryptographically strong 
PRNG, such as the ones discussed in Sections 7.2 and 7.3. In the next section, we 
look at a stream cipher that uses a PRNG designed specifically for the stream 
cipher. 


7.5 RC4 


RC4 is a stream cipher designed in 1987 by Ron Rivest for RSA Security. It is a vari- 
able key size stream cipher with byte-oriented operations. The algorithm is based on 
the use of a random permutation. Analysis shows that the period of the cipher is over- 
whelmingly likely to be greater than 10!”° [ROBS95a]. Eight to sixteen machine oper- 
ations are required per output byte, and the cipher can be expected to run very 
quickly in software. RC4 is used in the Secure Sockets Layer/Transport Layer Security 
(SSL/TLS) standards that have been defined for communication between Web 
browsers and servers. It is also used in the Wired Equivalent Privacy (WEP) protocol 
and the newer WiFi Protected Access (WPA) protocol that are part of the IEEE 
802.11 wireless LAN standard. RC4 was kept as a trade secret by RSA Security. In 
September 1994, the RC4 algorithm was anonymously posted on the Internet on the 
Cypherpunks anonymous remailers list. 
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The RC4 algorithm is remarkably simple and quite easy to explain. A vari- 
able-length key of from 1 to 256 bytes (8 to 2048 bits) is used to initialize a 256-byte 
state vector S, with elements S[0],S[1], ...,S[255]. At all times, S contains a permu- 
tation of all 8-bit numbers from 0 through 255. For encryption and decryption, a 
byte k (see Figure 7.5) is generated from S by selecting one of the 255 entries in a 
systematic fashion. As each value of k is generated, the entries in S are once again 
permuted. 


Initialization of S 


To begin, the entries of S are set equal to the values from 0 through 255 in ascending 
order; that is, S[0] = 0, S[1] = 1, ...,S[255] = 255. A temporary vector, T, is also 
created. If the length of the key K is 256 bytes, then T is transferred to T. Otherwise, 
for a key of length keylen bytes, the first keylen elements of T are copied from K, 
and then K is repeated as many times as necessary to fill out T. These preliminary 
operations can be summarized as 


/* Initialization */ 
for i = 0 to 255 do 
Stil sis 

T[i] = K[i mod keylen]; 


Next we use T to produce the initial permutation of S. This involves starting 
with S[0] and going through to S[255], and for each S[i], swapping S[i] with another 
byte in S according to a scheme dictated by T[i]: 


/* Initial Permutation of S */ 
j = 0; 
for i = 0 to 255 do 
5 (j + S[i] + T[i]) mod 256; 
Swap (S[1i], S[j]); 


Because the only operation on S is a swap, the only effect is a permutation. 
S still contains all the numbers from 0 through 255. 


Stream Generation 


Once the S vector is initialized, the input key is no longer used. Stream generation 
involves cycling through all the elements of S[i], and for each S[i], swapping S[i] with 
another byte in S according to a scheme dictated by the current configuration of S. 
After S[255] is reached, the process continues, starting over again at S[0]: 


/* Stream Generation */ 
i, j = 0; 
while (true) 

i = (1 + 1) mod 256; 

j = (3 + S[i]) mod 256; 
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Swap (S[il, S[j]); 
t = (S[il + S[j]) mod 256; 
k= Se ),s 


To encrypt, XOR the value k with the next byte of plaintext. To decrypt, XOR 
the value k with the next byte of ciphertext. 
Figure 7.6 illustrates the RC4 logic. 


Strength of RC4 


A number of papers have been published analyzing methods of attacking RC4 
(e.g., IKRNUD98], [MIST98], [FLUH00], [MANTO1]). None of these approaches is 
practical against RC4 with a reasonable key length, such as 128 bits. A more serious 
problem is reported in [FLUH01]. The authors demonstrate that the WEP proto- 
col, intended to provide confidentiality on 802.11 wireless LAN networks, is 
vulnerable to a particular attack approach. In essence, the problem is not with RC4 
itself but the way in which keys are generated for use as input to RC4. This partic- 
ular problem does not appear to be relevant to other applications using RC4 and 
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Figure 7.6 RC4 
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can be remedied in WEP by changing the way in which keys are generated. This 
problem points out the difficulty in designing a secure system that involves both 
cryptographic functions and protocols that make use of them. 


7.6 TRUE RANDOM NUMBER GENERATORS 


Entropy Sources 


A true random number generator (TRNG) uses a nondeterministic source to 
produce randomness. Most operate by measuring unpredictable natural processes, 
such as pulse detectors of ionizing radiation events, gas discharge tubes, and leaky 
capacitors. Intel has developed a commercially available chip that samples thermal 
noise by amplifying the voltage measured across undriven resistors [JUN99]. 
LavaRnd is an open source project for creating truly random numbers using 
inexpensive cameras, open source code, and inexpensive hardware. The system uses 
a saturated CCD in a light-tight can as a chaotic source to produce the seed. 
Software processes the result into truly random numbers in a variety of formats. 

RFC 4086 lists the following possible sources of randomness that, with care, 
easily can be used on a computer to generate true random sequences. 


e Sound/video input: Many computers are built with inputs that digitize some 
real-world analog source, such as sound from a microphone or video input 
from a camera. The “input” from a sound digitizer with no source plugged in or 
from a camera with the lens cap on is essentially thermal noise. If the system 
has enough gain to detect anything, such input can provide reasonably high 
quality random bits. 


e Disk drives: Disk drives have small random fluctuations in their rotational 
speed due to chaotic air turbulence [JAKO98]. The addition of low-level disk 
seek-time instrumentation produces a series of measurements that contain 
this randomness. Such data is usually highly correlated, so significant process- 
ing is needed. Nevertheless, experimentation a decade ago showed that, with 
such processing, even slow disk drives on the slower computers of that day 
could easily produce 100 bits a minute or more of excellent random data. 


There is also an online service (random.org), which can deliver random 
sequences securely over the Internet. 


Skew 


A TRNG may produce an output that is biased in some way, such as having more 
ones than zeros or vice versa. Various methods of modifying a bit stream to reduce 
or eliminate the bias have been developed. These are referred to as deskewing 
algorithms. One approach to deskew is to pass the bit stream through a hash func- 
tion, such as MD5 or SHA-1 (described in Chapter 11). The hash function produces 
an n-bit output from an input of arbitrary length. For deskewing, blocks of m input 
bits, with m = n, can be passed through the hash function. RFC 4086 recommends 
collecting input from multiple hardware sources and then mixing these using a hash 
function to produce random output. 
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Operating systems typically provide a built-in mechanism for generating ran- 
dom numbers. For example, Linux uses four entropy sources: mouse and keyboard 
activity, disk I/O operations, and specific interrupts. Bits are generated from these 
four sources and combined in a pooled buffer. When random bits are needed, the 
appropriate number of bits are read from the buffer and passed through the SHA-1 
hash function [GUTTO6]. 


7.7 RECOMMENDED READING AND WEB SITES 


Perhaps the best treatment of PRNGs is found in [KNUT98]. An alternative to the standard 
linear congruential algorithm, known as the linear recurrence algorithm, is explained in some 
detail in [BRIG79]. [ZENG91] assesses various PRNG algorithms for use in generating 
variable-length keys for Vernam types of ciphers. 

An excellent survey of PRNGs, with an extensive bibliography, is [RITT91]. 
[MENE97] also provides a good discussions of secure PRNGs. Another good treatment, with 
an emphasis on practical implementation issues, is RFC 4086 [EASTO0S5]. This RFC also 
describes a number of deskewing techniques. [KELS98] is a good survey of secure PRNG 
techniques and cryptanalytic attacks on them. SP 800-90 [BARKO7] provides a useful treat- 
ment of a variety of PRNGs recommended by NIST. SP 800-22 [RUKH08] defines and dis- 
cusses the 15 statistical tests of randomness recommended by NIST. 

[KUMA97] contains an excellent and lengthy discussion of stream cipher design prin- 
ciples. Another good treatment, quite mathematical, is [RUEP92]. [ROBS95a] is an interest- 
ing and worthwhile examination of many design issues related to stream ciphers. 


BARKO07 Barker, E., and Kelsey, J. Recommendation for Random Number Generation 
Using Deterministic Random Bit Generators. NIST SP 800-90, March 2007. 

BRIG79 Bright, H., and Enison, R. “Quasi-Random Number Sequences from Long- 
Period TLP Generator with Remarks on Application to Cryptography.” Computing 
Surveys, December 1979. 

EAST05 Eastlake, D.; Schiller, J.; and Crocker, S. Randomness Requirements for Security. 
RFC 4086, June 2005. 

KELS98_ Kelsey, J.; Schneier, B.; and Hall, C. “Cryptanalytic Attacks on Pseudorandom 
Number Generators.” Proceedings, Fast Software Encryption, 1998. http:// 
www.schneier.com/paper-prngs.html 

KNUT98_ Knuth, D. The Art of Computer Programming, Volume 2: Seminumerical 
Algorithms. Reading, MA: Addison-Wesley, 1998. 

KUMA97_ Kumar, I. Cryptology. Laguna Hills, CA: Aegean Park Press, 1997. 

MENE97 Menezes, A.; Oorshcot, P.; and Vanstone, S. Handbook of Applied 
Cryptography. Boca Raton, FL: CRC Press, 1997. 

ROBS95a_Robshaw, M. Stream Ciphers. RSA Laboratories Technical Report TR-701, 
July 1995. 

RITT91_ Ritter, T. “The Efficient Generation of Cryptographic Confusion Sequences.” 
Cryptologia, vol. 15 no. 2, 1991. www.ciphersbyritter.com/ARTS/CRNG2ART.HTM 

RUEP92 Rueppel, T. “Stream Ciphers.” In [SIMM92]. 
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RUKHO08_ Rukhin, A., et al. A Statistical Test Suite for Random and Pseudorandom 
Number Generators for Cryptographic Applications. NIST SP 800-22, August 2008. 


SIMM92 Simmons, G., ed. Contemporary Cryptology: The Science of Information 


Integrity. Piscataway, NJ: IEEE Press, 1992. 


ZENG91 Zeng, K.; Yang, C.; Wei, D.; and Rao, T. “Pseudorandom Bit Generators in 
Stream-Cipher Cryptography.” Computer, February 1991. 


Recommended Web Sites: 


e NIST Random Number Generation Technical Working Group: Contains documents 
and tests developed by NIST that related to PRNGs for cryptographic applications. 
Also has useful set of links. 


e NIST Random Number Generation Cryptographic Toolkit: Another useful NIST site 
with documents and links. 


e LavaRnd: LavaRnd is an open source project that uses a chaotic source to generate 
truly random numbers. The site also has background information on random numbers 
in general. 


e Quantum Random Numbers: You can access quantum random numbers on the 
fly here. 


e RandomNumber.org: Another source of random numbers. 
e A Million Random Digits: Compiled by the RAND Corporation. 


7.8 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


backward unpredictability pseudorandom function stream cipher 

Blum, Blum, Shub generator (PRF) skew 

deskewing pseudorandom number true random number 
entropy source generator (PRNG) generator (TRNG) 


forward unpredictability randomness unpredictability 
keystream RC4 
linear congruential generator seed 


Review Questions 


7.1 What is the difference between statistical randomness and unpredictability? 
7.2. List important design considerations for a stream cipher. 

7.3 Why is it not desirable to reuse a stream cipher key? 

7.4 What primitive operations are used in RC4? 
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Problems 


71 


7.4 


Pind 
in 


7.6 


If we take the linear congruential algorithm with an additive component of 0, 
Xn+1 = (aX,) mod m 


Then it can be shown that if m is prime and if a given value of a produces the maxi- 
mum period of m — 1, then a‘ will also produce the maximum period, provided that 
k is less than m and that k and m — 1 are relatively prime. Demonstrate this by using 
Xo = 1 and m = 31 and producing the sequences for a* = 3,37, 3°, and 3°. 
a. What is the maximum period obtainable from the following generator? 


X41 = (aX,,)mod2* 


b. What should be the value of a? 
c. What restrictions are required on the seed? 


You may wonder why the modulus m = 2°! — 1 was chosen for the linear congruen- 
tial method instead of simply 2°!, because this latter number can be represented with 
no additional bits and the mod operation should be easier to perform. In general, the 
modulus 2* — 1 is preferable to 2. Why is this so? 


With the linear congruential algorithm, a choice of parameters that provides a full 
period does not necessarily provide a good randomization. For example, consider the 
following two generators: 


Xn+1 = (6X,) mod 13 
Xray = (7X,) mod 13 


Write out the two sequences to show that both are full period. Which one appears 
more random to you? 


In any use of pseudorandom numbers, whether for encryption, simulation, or statis- 
tical design, it is dangerous to trust blindly the random number generator that 
happens to be available in your computer’s system library. [PARK88] found that 
many contemporary textbooks and programming packages make use of flawed 
algorithms for pseudorandom number generation. This exercise will enable you to 
test your system. 


The test is based on a theorem attributed to Ernesto Cesaro (see [KNUT98] for 
a proof), which states the following: Given two randomly chosen integers, x and y, 
the probability that gcd(x,y) = 1 is 6/7”. Use this theorem in a program to deter- 
mine statistically the value of 7.The main program should call three subprograms: 
the random number generator from the system library to generate the random inte- 
gers; a subprogram to calculate the greatest common divisor of two integers using 
Euclid’s Algorithm; and a subprogram that calculates square roots. If these latter 
two programs are not available, you will have to write them as well. The main pro- 
gram should loop through a large number of random numbers to give an estimate of 
the aforementioned probability. From this, it is a simple matter to solve for your 
estimate of 7. 


If the result is close to 3.14, congratulations! If not, then the result is probably low, 
usually a value of around 2.7. Why would such an inferior result be obtained? 


Suppose you have a true random bit generator where each bit in the generated 
stream has the same probability of being a 0 or 1 as any other bit in the stream and 
that the bits are not correlated; that is the bits are generated from identical indepen- 
dent distribution. However, the bit stream is biased. The probability of a 1 is 
0.5 + @ and the probability of a 0 is n, where 0 < 0 < 0.5.A simple deskewing 
algorithm is as follows: Examine the bit stream as a sequence of non-overlapping 
pairs. Discard all 00 and 11 pairs. Replace each 01 pair with 0 and each 10 pair with 1. 
a. What is the probability of occurrence of each pair in the original sequence? 

b. What is the probability of occurrence of 0 and 1 in the modified sequence? 

c. What is the expected number of input bits to produce x output bits? 


| 


7.8 


7.9 


7.10 
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d. Suppose that the algorithm uses overlapping successive bit pairs instead of 
nonoverlapping successive bit pairs. That is, the first output bit is based on input 
bits 1 and 2, the second output bit is based on input bits 2 and 3, and so on. What 
can you say about the output bit stream? 


Another approach to deskewing is to consider the bit stream as a sequence of non- 

overlapping groups of n bits each and output the parity of each group. That is, if a 

group contains an odd number of ones, the output is 1; otherwise the output is 0. 

a. Express this operation in terms of a basic Boolean function. 

b. Assume, as in the preceding problem, that the probability of a 1 is 0.5 + 0. If each 
group consists of 2 bits, what is the probability of an output of 1? 

c. If each group consists of 4 bits, what is the probability of an output of 1? 

d. Generalize the result to find the probability of an output of 1 for input groups of 
n bits. 


What RC4 key value will leave S unchanged during initialization? That is, after the 
initial permutation of S, the entries of S will be equal to the values from 0 through 255 
in ascending order. 


RC¢4 has a secret internal state which is a permutation of all the possible values of the 

vector S and the two indices / and j. 

a. Using a straightforward scheme to store the internal state, how many bits are 
used? 

b. Suppose we think of it from the point of view of how much information is repre- 
sented by the state. In that case, we need to determine how may different states 
there are, then take the log to base 2 to find out how many bits of information this 
represents. Using this approach, how many bits would be needed to represent the 
state? 

Alice and Bob agree to communicate privately via email using a scheme based on 

RC4, but they want to avoid using a new secret key for each transmission. Alice and 

Bob privately agree on a 128-bit key k. To encrypt a message m, consisting of a string 

of bits, the following procedure is used. 

1. Choose a random 80-bit value v 

2. Generate the ciphertext c = RC4(v ||k) ® m 

3. Send the bit string (v || c) 


a. Suppose Alice uses this procedure to send a message m to Bob. Describe how Bob 
can recover the message m from (v || c) using k. 

b. If an adversary observes several values (vj || c1), (v2 || c2),... transmitted between 
Alice and Bob, how can he/she determine when the same key stream has been 
used to encrypt two messages? 

c. Approximately how many messages can Alice expect to send before the same key 
stream will be used twice? Use the result from the birthday paradox described in 
Appendix 11A [Equation (11.7)]. 

d. What does this imply about the lifetime of the key k (1.e., the number of messages 
that can be encrypted using k)? 
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The Devil said to Daniel Webster: “Set me a task I can’t carry out, and I'll give 
you anything in the world you ask for.” 
Daniel Webster: “Fair enough. Prove that for n greater than 2, the equation 


a’ + b” = c" has no non-trivial solution in the integers.” 
They agreed on a three-day period for the labor, and the Devil 
disappeared. 


At the end of three days, the Devil presented himself, haggard, jumpy, biting 
his lip. Daniel Webster said to him, “Well, how did you do at my task? Did you 
prove the theorem?” 

“Eh? No... no, I haven't proved it.” 

“Then I can have whatever I ask for? Money? The Presidency?” 

“What? Oh, that—of course. But listen! If we could just prove the following 
two lemmas—” 

—The Mathematical Magpie, Clifton Fadiman 


KEY POINTS 


® A prime number is an integer that can only be divided without remainder 
by positive and negative values of itself and 1. Prime numbers play a 
critical role both in number theory and in cryptography. 


® Two theorems that play important roles in public-key cryptography are 
Fermat’s theorem and Euler’s theorem. 

® Animportant requirement in a number of cryptographic algorithms is the 
ability to choose a large prime number. An area of ongoing research is the 
development of efficient algorithms for determining if a randomly chosen 
large integer is a prime number. 

® Discrete logarithms are fundamental to a number of public-key algorithms. 
Discrete logarithms are analogous to ordinary logarithms but are defined 
using modular arithmetic. 


A number of concepts from number theory are essential in the design of public-key 
cryptographic algorithms. This chapter provides an overview of the concepts referred 
to in other chapters. The reader familiar with these topics can safely skip this chapter. 
The reader should also review Sections 4.1 through 4.3 before proceeding with this 


chapter. 


As with Chapter 4, this chapter includes a number of examples, each of which is 


highlighted in a shaded box. 
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8.1 PRIME NUMBERS! 


A central concern of number theory is the study of prime numbers. Indeed, whole 
books have been written on the subject (e.g., [CRANO1], [RIBE96]). In this section, 
we provide an overview relevant to the concerns of this book. 

An integer p > 1 is a prime number if and only if its only divisors“ are +1 and 

+ p. Prime numbers play a critical role in number theory and in the techniques dis- 

cussed in this chapter. Table 8.1 shows the primes less than 2000. Note the way the 
primes are distributed. In particular, note the number of primes in each range of 100 
numbers. 

Any integer a > 1 can be factored in a unique way as 


2 


a= pt X pp X +++ X pr (8.1) 


where p; < p2 < ... < p,;are prime numbers and where each q; is a positive integer. 
This is known as the fundamental theorem of arithmetic; a proof can be found in any 
text on number theory. 


91=7 xX 13 
3600 = 24 x 32 x § 


NOM = fel 


It is useful for what follows to express this another way. If P is the set of all prime 
numbers, then any positive integer a can be written uniquely in the following form: 


a= [[p” where each a, = 0 
peEP 
The right-hand side is the product over all possible prime numbers p; for any partic- 
ular value of a, most of the exponents a, will be 0. 
The value of any given positive integer can be specified by simply listing all the 
nonzero exponents in the foregoing formulation. 


The integer 12 is represented by {ay = 2, a3 = 1}. 
The integer 18 is represented by {ay = 1, a; = 2}. 


The integer 91 is represented by {a7 = 1, a3 = 1}. 


Multiplication of two numbers is equivalent to adding the corresponding expo- 


nents. Given a = [ Ip”. b= T[p”. Define k = ab. We know that the integer 
peEP peEP 


Tn this section, unless otherwise noted, we deal only with the nonnegative integers. The use of negative 
integers would introduce no essential differences. 

?Recall from Chapter 4 that integer a is said to be a divisor of integer b if there is no remainder on divi- 
sion. Equivalently, we say that a divides b. 


OVE 


fable 8.1 Primes Under 2000 
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k can be expressed as the product of powers of primes: k = [| p*». It follows that 
k, =a, + b, forall p € P. peP 


i NOS 0a 3 OG 


i 
DIE Se SE SOT 


What does it mean, in terms of the prime factors of a and b, to say that a divides b? 
Any integer of the form p” can be divided only by an integer that is of a lesser 
or equal power of the same prime number, p/ with j < n. Thus, we can say the 
following. 

Given 


a= I] »”. b= I] vp” 
pEP pEP 
If alb, then a, = b, for all p. 


a = 12-6) = 361286 
12 2 336 = 
a =2=b, 
a,=152=b, 


Thus, the inequality a, = b, is satisfied for all prime numbers. 


It is easy to determine the greatest common divisor? of two positive integers if 
we express each integer as the product of primes. 


B00 5. 5” 
18 = 2! x 3 


scd(18, 300) = 2) x 3) x59 =6 


The following relationship always holds: 
Ifk = gced(a, b), then k, = min(a,, b,) for all p. 


Determining the prime factors of a large number is no easy task, so the pre- 
ceding relationship does not directly lead to a practical method of calculating the 
greatest common divisor. 


Recall from Chapter 4 that the greatest common divisor of integers a and b, expressed (gcd a, b), is an 
integer c that divides both a and b without remainder and that any divisor of a and b is a divisor of c 
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8.2 FERMAT’S AND EULER’S THEOREMS 


Two theorems that play important roles in public-key cryptography are Fermat’s 
theorem and Euler’s theorem. 


Fermat’s Theorem* 


Fermat’s theorem states the following: If p is prime and a is a positive integer not 
divisible by p, then 


a?~! = 1(mod p) (8.2) 


Proof: Consider the set of positive integers less than p: {1,2, ...,p — 1} and 
multiply each element by a, modulo p, to get the set X = {amodp, 
2a modp, ...,(p — 1)amodp}. None of the elements of X is equal to zero because 
Pp does not divide a. Furthermore, no two of the integers in X are equal.To see this, 
assume that ja = ka(mod p)), where 1 = j < k S p — 1. Because a is relatively 
prime to p, we can eliminate a from both sides of the equation [see Equation (4.3)] 
resulting in j = k(mod p). This last equality is impossible, because j and k are both 
positive integers less than p. Therefore, we know that the (p — 1) elements of X are 
all positive integers with no two elements equal. We can conclude the X consists of 
the set of integers {1,2, ..., p — 1} in some order. Multiplying the numbers in both 
sets (p and X) and taking the result mod p yields 


aX2aX... X(p— a= [1 X2*X ... X (p — 1)] (modp) 
a?~'(p — 1)! = (p — 1)!(mod p) 


We can cancel the ((p — 1)! term because it is relatively prime to p [see Equation 
(4.5)]. This yields Equation (8.2), which completes the proof. 


a=7,p =19 
7 = 49 = 11 (mod19) 
7’ = 121 = 7 (mod19) 


7° = 49 = 11 (mod19) 
76 = 121 = 7 (mod 19) 
Ga =e = ey = 7x I= I (mod19) 


An alternative form of Fermat’s theorem is also useful: If p is prime and ais a 
positive integer, then 


a? = a(mod p) (8.3) 


‘This is sometimes referred to as Fermat's little theorem. 

Recall from Chapter 4 that two numbers are relatively prime if they have no prime factors in common; 
that is, their only common divisor is 1. This is equivalent to saying that two numbers are relatively prime 
if their greatest common divisor is 1. 
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Note that the first form of the theorem [Equation (8.2)] requires that a be relatively 
prime to p, but this form does not. 


a? = 3° = 243 = 3(mod5) = a(modp) 


=10 a? = 10° = 100000 = 10(mod5) = 0(mod5) = a(modp) 


Euler’s Totient Function 


Before presenting Euler’s theorem, we need to introduce an important quantity in 
number theory, referred to as Euler’s totient function, written ¢(1), and defined as 
the number of positive integers less than n and relatively prime to n. By convention, 


o(1) = 1. 


DETERMINE (37) AND (35). 


Because 37 is prime, all of the positive integers from 1 through 36 are rela- 
tively prime to 37. Thus (37) = 36. 


To determine $(35), we list all of the positive integers less than 35 that are rela- 


tively prime to it: 


Ih, 2y So SEG, fh, G), WIL, 12, 1B), Iles, 177, 1kss 
9), 22, D3, MA, Bo, VI, QS), Sil, BW, 333), 34 


There are 24 numbers on the list, so #(35) = 24. 


Table 8.2 lists the first 30 values of 6(1). The value (1) is without meaning but 
is defined to have the value 1. 
It should be clear that, for a prime number p, 


d(p) =p-1 


Now suppose that we have two prime numbers p and q with p # q. Then we can 
show that, for n = pq, 


b(n) = o(pq) = oP) X (2) = (P- 1) X (a - 1) 


To see that d(n) = o(p) X (q), consider that the set of positive integers less that n 
is the set {1, ..., (pq — 1)}.The integers in this set that are not relatively prime to 
are the set {p, 2p, ...,(q — 1)p} and the set {g, 2g, ..., (p — 1)q}. Accordingly, 


ln) = (pg= 1) = [te = 1) +(e = 1] 
= po=— (eer gy rd 
=(p=1) x @ = 1) 
= $(p) X (9) 
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Table 8.2 Some Values of Euler’s Totient Function ¢(1) 


3 


— 


1 
2) 
3 
4 
5 
6 
W 
8 


IDI I DIMI ITV [VIr 


f 


6(21) = (3) X 6(7) = 3-1) xX (7-1) =2 X6=12 
where the 12 integers are {1,2, 4,5, 8, 10, 11, 13, 16, 17, 19, 20}. 


Euler’s Theorem 


Euler’s theorem states that for every a and n that are relatively prime: 


a?*) = 1(modn) (8.4) 


Proof: Equation (8.4) is true if n is prime, because in that case, b(n) = (n — 1) 
and Fermat’s theorem holds. However, it also holds for any integer n. Recall that 
o(n) is the number of positive integers less than n that are relatively prime to n. 
Consider the set of such integers, labeled as 


R= {x1, XQ, s0- Xan} 


That is, each element x; of R is a unique positive integer less than n with 
gcd(x;,) = 1. Now multiply each element by a, modulo n: 


S = {(ax,;mod n), (ax,mod n), ..., (aX) mod n)} 
The set S is a permutation® of R, by the following line of reasoning: 
1. Because a is relatively prime to n and x; is relatively prime to n, ax; must also 


be relatively prime to n. Thus, all the members of S are integers that are less 
than n and that are relatively prime to n. 


Recall from Chapter 2 that a permutation of a finite set of elements S is an ordered sequence of all the 
elements of S, with each element appearing exactly once. 
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2. There are no duplicates in S. Refer to Equation (4.5). If ax; mod n 


= ax; mod n,thenx; = x). 


Therefore, 
o(n) (x) 
[[(ax;mod n) = [] x; 
i=l ist 
o(n) o(n) 


[ ax; = []x:(mod n) 


i=1 i=1 


o(n) $(n) 
a®™ | T]x; | = [] «(mod n) 
i=1 i=1 


a®*”) = 1(mod n) 


which completes the proof. This is the same line of reasoning applied to the proof of 
Fermat’s theorem. 


= 10; 60) =4 a?) = 3" = 81) = med 10) — 1 Gnedin) 


=i oly = 10 2) — 2 1004 = (modi) = 1 (modn) 


As is the case for Fermat’s theorem, an alternative form of the theorem is also 
useful: 


a®™*! = a(mod n) (8.5) 


Again, similar to the case with Fermat’s theorem, the first form of Euler’s theorem 
[Equation (8.4)] requires that a be relatively prime to n, but this form does not. 


8.3 TESTING FOR PRIMALITY 


For many cryptographic algorithms, it is necessary to select one or more very large 
prime numbers at random. Thus, we are faced with the task of determining whether 
a given large number is prime. There is no simple yet efficient means of accomplish- 
ing this task. 

In this section, we present one attractive and popular algorithm. You may be 
surprised to learn that this algorithm yields a number that is not necessarily a 
prime. However, the algorithm can yield a number that is almost certainly a prime. 
This will be explained presently. We also make reference to a deterministic algo- 
rithm for finding primes. The section closes with a discussion concerning the distri- 
bution of primes. 
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Miller-Rabin Algorithm’ 


The algorithm due to Miller and Rabin [MILL75, RABI80] is typically used to test a 
large number for primality. Before explaining the algorithm, we need some back- 
ground. First, any positive odd integer n = 3 can be expressed as 


n-1=2*%q — withk > 0,qodd 


To see this, note that m — 1 is an even integer. Then, divide (mn — 1) by 2 until the 
result is an odd number q, for a total of k divisions. If n is expressed as a binary num- 
ber, then the result is achieved by shifting the number to the right until the rightmost 
digit is a 1, for a total of k shifts. We now develop two properties of prime numbers 
that we will need. 


Two PROPERTIES OF PRIME NumBeRS The first property is stated as follows: If p is 
prime and ais a positive integer less than p, then a*mod p = 1 if and only if either 
amod p = loramod p = —1 mod p = p — 1. By the rules of modular arithmetic 
(amod p)(amod p) = a’mod p. Thus, if either amodp = loramod p = —1, 
thena* mod p = 1. Conversely, if a7mod p = 1, then (amod p)* = 1, which is true 
only for amod p = 1 oramod p = —1 

The second property is stated as follows: Let p be a prime number greater 
than 2. We can then write p — 1 = 2*q with k > 0, q odd. Let a be any integer in 
the range 1 < a < p — 1.Then one of the two following conditions is true. 


1. a’ is congruent to 1 modulo p. That is, a’modp = 1, or equivalently, 
a! = 1(mod p). 

2. One of the numbers a%, a4, a4, ..., a "is congruent to —1 modulo p. That 
is, there is some number j in the range (1 = j =k) such that a4 
modp = —1 mod p = p — 1 or equivalently, a t= —1(modp). 


Proof: Fermat’s theorem [Equation (8.2)] states that a’! = 1(modn) if n is 
k 

prime. We have p — 1 = 2*q. Thus, we know that a?-!'mod p = a’ 4mod p = 1. 

Thus, if we look at the sequence of numbers 


al mod p, a4 mod p, a“ mod p, ..., a "mod p, a4 mod p (8.6) 


we know that the last number in the list has value 1. Further, each number in the list 
is the square of the previous number. Therefore, one of the following possibilities 
must be true. 


1. The first number on the list, and therefore all subsequent numbers on the list, 
equals 1. 

2. Some number on the list does not equal 1, but its square mod p does equal 1. 
By virtue of the first property of prime numbers defined above, we know that 
the only number that satisfies this condition is p — 1. So, in this case, the list 
contains an element equal to p — 1. 


This completes the proof. 


TAlso referred to in the literature as the Rabin-Miller algorithm, or the Rabin-Miller test, or the Miller- 
Rabin test. 
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DETAILS OF THE ALGORITHM These considerations lead to the conclusion that, if 7 is 
prime, then either the first element in the list of residues, or remainders, 
(a!,a°4, a a4, a’) modulo n equals 1; or some element in the list equals 
(n — 1); otherwise n is composite (1.e., not a prime). On the other hand, if the 
condition is met, that does not necessarily mean that n is prime. For example, if 
n = 2047 = 23 X 89,then n — 1 = 2 X 1023. We compute 2'° mod 2047 = 1, so 
that 2047 meets the condition but is not prime. 

We can use the preceding property to devise a test for primality. The procedure 
TEST takes a candidate integer n as input and returns the result composite if n is 
definitely not a prime, and the result inconclusive if m may or may not be a prime. 


TEST (n) 

1. Find integers k, q, with k> 0, q odd, so that 
a= 12a); 

Select a random integer a,l<a<n-l1; 


if a%modn = 1 then return("inconclusive"); 
for j=0 to k— 1 do 
if a?%modn=n-—1 then return("inconclusive"); 


aA uF WwW ND 


" . " 
return( composite ); 


Let us apply the test to the prime number n=29. We have 
(n — 1) = 28 = 2°(7) = 2*q. First, let us try a=10. We compute 
10’ mod 29 = 17, which is neither 1 nor28,so we continue the test. The next calcu- 
lation finds that (10’)? mod 29 = 28, and the test returns inconclusive (i.e., 29 
may be prime). Let’s try again with a = 2. We have the following calculations: 
27 mod 29 = 12;2'4mod 29 = 28; and the test again returns inconclusive. If 
we perform the test for all integers a in the range 1 through 28, we get the same 
inconclusive result, which is compatible with n being a prime number. 

Now let us apply the test to the composite number n = 13 X 17 = 221. 
Then (n—1) = 220 = 27(55) = 2*q. Let us try a=5. Then we have 
5% mod 221 = 112, which is neither 1 nor220(5°°)? mod 221 = 168. Because we 
have used all values of j (i.e., 7 = 0 and j = 1) in line 4 of the TEST algorithm, 
the test returns composite, indicating that 221 is definitely a composite num- 
ber. But suppose we had selected a = 21. Then we have 21° mod 221 = 200; 
(21°°)? mod 221 = 220; and the test returns inconclusive, indicating that 221 
may be prime. In fact, of the 218 integers from 2 through 219, four of these will 
return an inconclusive result, namely 21, 47, 174, and 200. 


REPEATED USE OF THE MILLER-RABIN ALGORITHM How can we use the Miller- 
Rabin algorithm to determine with a high degree of confidence whether or not an 
integer is prime? It can be shown [KNUT98] that given an odd number vn that is not 
prime and a randomly chosen integer, a with 1 < a < n — 1, the probability that 
TEST will return inconclusive (i.e., fail to detect that n is not prime) is less than 
1/4. Thus, if t different values of a are chosen, the probability that all of them will 
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pass TEST (return inconclusive) for 7 is less than (1/4)'. For example, for ¢ = 10, the 
probability that a nonprime number will pass all ten tests is less than 10°. Thus, for 
a sufficiently large value of t, we can be confident that n is prime if Miller’s test 
always returns inconclusive. 

This gives us a basis for determining whether an odd integer v is prime with a rea- 
sonable degree of confidence. The procedure is as follows: Repeatedly invoke TEST 
(n) using randomly chosen values for a. If, at any point, TEST returns composite, 
then n is determined to be nonprime. If TEST continues to return inconclusive for 
t tests, then for a sufficiently large value of t, assume that n is prime. 


A Deterministic Primality Algorithm 


Prior to 2002, there was no known method of efficiently proving the primality of 
very large numbers. All of the algorithms in use, including the most popular 
(Miller-Rabin), produced a probabilistic result. In 2002, Agrawal, Kayal, and 
Saxena [AGRAO2] developed a relatively simple deterministic algorithm that effi- 
ciently determines whether a given large number is a prime. The algorithm, known 
as the AKS algorithm, does not appear to be as efficient as the Miller-Rabin algorithm. 
Thus far, it has not supplanted this older, probabilistic technique [BORNO3]. 


Distribution of Primes 


It is worth noting how many numbers are likely to be rejected before a prime number 
is found using the Miller-Rabin test, or any other test for primality. A result from num- 
ber theory, known as the prime number theorem, states that the primes near n are 
spaced on the average one every (In 1) integers. Thus, on average, one would have to 
test on the order of In() integers before a prime is found. Because all even integers 
can be immediately rejected, the correct figure is 0.5 In(7). For example, if a prime on 
the order of magnitude of 27° were sought, then about 0.5 In(2””) = 69 trials would 
be needed to find a prime. However, this figure is just an average. In some places along 
the number line, primes are closely packed, and in other places there are large gaps. 


The two consecutive odd integers 1,000,000,000,061 and 1,000,000,000,063 are both 
prime. On the other hand, 1001! + 2, 1001! + 3,..., 1001! + 1000, 1001! + 1001 


is a sequence of 1000 consecutive composite integers. 


8.4 THE CHINESE REMAINDER THEOREM 


One of the most useful results of number theory is the Chinese remainder theorem 
(CRT).® In essence, the CRT says it is possible to reconstruct integers in a certain 
range from their residues modulo a set of pairwise relatively prime moduli. 


’The CRT is so called because it is believed to have been discovered by the Chinese mathematician 
Sun-Tsu in around 100 A.D. 
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The 10 integers in Zo, that is the integers 0 through 9, can be reconstructed from 
their two residues modulo 2 and 5 (the relatively prime factors of 10). Say the 
Known residues of a decimal digit x are r7 = 0 and rs = 3; that is, x mod 2 = 0 


and x mod 5 = 3. Therefore, x is an even integer in Z,) whose remainder, on 
division by 5, is 3. The unique solution is x = 8. 


The CRT can be stated in several ways. We present here a formulation that is 
most useful from the point of view of this text. An alternative formulation is 
explored in Problem 8.17. Let 


k 
M= II m 
i=1 


where the m; are pairwise relatively prime; that is, gcd(m;,m;) = 1 for1 = i,j = k, 
andi # j.We can represent any integer A in Z, by a k-tuple whose elements are in 
Zm, using the following correspondence: 


A= (aj, do, ..-, Ay) (8.7) 


where A € Zy, a; © Z,,, and a; = A mod m; for 1 = i = k. The CRT makes two 
assertions. 


1. The mapping of Equation (8.7) is a one-to-one correspondence (called a 
bijection) between Zy and the Cartesian product Z,,, * Zm,X ... X Zn, 
That is, for every integer A such that 0 = A = M, there is a unique k-tuple 
(ay, ao, ..., ay) with 0 S a; < m; that represents it, and for every such k-tuple 
(ay, ao, ..., ay), there is a unique integer A in Zy. 


N 


. Operations performed on the elements of Z, can be equivalently performed 
on the corresponding k-tuples by performing the operation independently in 
each coordinate position in the appropriate system. 


Let us demonstrate the first assertion. The transformation from A to 


(ay, 4o,..., 4%), is obviously unique; that is, each a; is uniquely calculated as 
a; = Amod m;. Computing A from (aj, a, ...,a,) can be done as follows. Let 
M; = M/m,for1 =i=<=k. Note that M; =m, X MX ... X M1 X Myx, X «.. 


X my, sothat M; = 0(mod m)) for all j # i. Then let 
c= M; x (M;'modm;)  forl <i =k (8.8) 


By the definition of M,, it is relatively prime to m; and therefore has a unique multi- 
plicative inverse mod m,. So Equation (8.8) is well defined and produces a unique 
value c;. We can now compute 


k 
A= aici (mod M) (8.9) 
i-1 
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To show that the value of A produced by Equation (8.9) is correct, we must 
show that a; = Amodm, for 1 = i = k. Note that c; = M; = 0(mod m,) if j # i, 
and that c; = 1(mod m,). It follows that a; = Amod m,. 

The second assertion of the CRT, concerning arithmetic operations, follows from 
the rules for modular arithmetic. That is, the second assertion can be stated as follows: If 


A (a, d, ..., A) 
B <= (by, bo, ..., by) 
then 
(A + B)mod M <= ((a, + b,) mod m, ..., (ax + by) mod mx) 
(A — B)mod M <= ((aq, — b;) mod m, ..., (a, — by) mod mx) 
(A X B)mod M <= ((aq, X b,) mod m, ..., (ax X by) mod mx) 


One of the useful features of the Chinese remainder theorem is that it pro- 
vides a way to manipulate (potentially very large) numbers mod M in terms of 
tuples of smaller numbers. This can be useful when M is 150 digits or more. 
However, note that it is necessary to know beforehand the factorization of M. 


To represent 973 mod 1813 as a pair of numbers mod 37 and 49, define? 


m, = 37 
my = 49 
M = 1813 
A = 973 


We also have M, = 49 and M, = 37. Using the extended Euclidean algorithm, 
we compute M;! = 34 mod m, and Mj! = 4 mod mp. (Note that we only need 
to compute each M; and each M;! once.) Taking residues modulo 37 and 49, our 
representation of 973 is (11, 42), because 973 mod 37 = 11 and 973 mod 49 = 42. 

Now suppose we want to add 678 to 973. What do we do to (11, 42)? First 
we compute (678) < (678 mod 37, 678 mod 49) = (12,41). Then we add the 
tuples element-wise and reduce (11 + 12 mod 37, 42 + 41 mod 49) = (23, 34). 
To verify that this has the correct effect, we compute 


(23, 34) <> a,M,M;! + ayM)M;z' mod M 

= [(23)(49)(34) + (34)(37)(4)] mod 1813 
43350 mod 1813 
= los) 


and check that it is equal to (973 + 678) mod 1813 = 1651. Remember that in the 
above derivation, M;! is the multiplicative inverse of M; modulo m,; modulo M3! is 
the multiplicative inverse of M> modulo mp. 


°This example was provided by Professor Ken Calvert of Georgia Tech. 


8.5 / DISCRETE LOGARITHMS 257 


Suppose we want to multiply 1651 (mod 1813) by 73. We multiply (23, 34) 
by 73 and reduce to get (23 X 73 mod 37, 34 X 73 mod 49) = (14, 32). It is eas- 
ily verified that 


(14, 32) = [(14)(49)(34) + (32)(37)(4)] mod 1813 
= 865 


= 1651 X 73 mod 1813 


8.5 DISCRETE LOGARITHMS 


Discrete logarithms are fundamental to a number of public-key algorithms, includ- 
ing Diffie-Hellman key exchange and the digital signature algorithm (DSA). This 
section provides a brief overview of discrete logarithms. For the interested reader, 
more detailed developments of this topic can be found in [ORE67] and [LEVE90]. 


The Powers of an Integer, Modulo n 
Recall from Euler’s theorem [Equation (8.4)] that, for every a and n that are rela- 
tively prime, 


a®*”) = 1 (mod n) 


where (n), Euler’s totient function, is the number of positive integers less than n 
and relatively prime to n. Now consider the more general expression: 


a” = 1(modn) (8.10) 


If a and n are relatively prime, then there is at least one integer m that satisfies 
Equation (8.10), namely, M = ¢(n). The least positive exponent m for which 
Equation (8.10) holds is referred to in several ways: 


e The order of a (mod n) 
e The exponent to which a belongs (mod n) 
e The length of the period generated by a 


To see this last point, consider the powers of 7, modulo 19: 


T= 7 (mod 19) 
7 =49=2 19 11 =  11(mod 19) 
7 = 3437-18 19 2 = 1(mod19) 
7 = 2401 = 126X19+7 = 7(mod19) 


T = 16807 = 884 X 19+ 11= 11 (mod 19) 
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There is no point in continuing because the sequence is repeating. This can be 
proven by noting that 7? = 1(mod 19), and therefore, 7°*/ = 7°7/ = 7/(mod 19), 
and hence, any two powers of 7 whose exponents differ by 3 (or a multiple of 3) 
are congruent to each other (mod 19). In other words, the sequence is periodic, 
and the length of the period is the smallest positive exponent m such that 


a7 m 


= 1(mod 19). 


Table 8.3 shows all the powers of a, modulo 19 for all positive a < 19.The length 


of the sequence for each base value is indicated by shading. Note the following: 


1. 


All sequences end in 1. This is consistent with the reasoning of the preceding 
few paragraphs. 


. The length of a sequence divides 6(19) = 18. That is, an integral number of 


sequences occur in each row of the table. 


. Some of the sequences are of length 18. In this case, it is said that the base inte- 


ger a generates (via powers) the set of nonzero integers modulo 19. Each such 
integer is called a primitive root of the modulus 19. 


8.3 Powers of Integers, Modulo 19 
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More generally, we can say that the highest possible exponent to which a num- 
ber can belong (mod n) is ¢(n). If a number is of this order, it is referred to as a 
primitive root of n. The importance of this notion is that if a is a primitive root of n, 
then its powers 


a, a, ...,a° 


are distinct (mod 7) and are all relatively prime to n. In particular, for a prime num- 
ber p,if ais a primitive root of p, then 


are distinct (mod p). For the prime number 19, its primitive roots are 2, 3, 10, 13, 14, 
and 15. 

Not all integers have primitive roots. In fact, the only integers with primitive 
roots are those of the form 2, 4, p*, and 2p*, where p is any odd prime and a is a 
positive integer. The proof is not simple but can be found in many number theory 
books, including [ORE76]. 


Logarithms for Modular Arithmetic 


With ordinary positive real numbers, the logarithm function is the inverse of expo- 
nentiation. An analogous function exists for modular arithmetic. 

Let us briefly review the properties of ordinary logarithms. The logarithm of a 
number is defined to be the power to which some positive base (except 1) must be 
raised in order to equal the number. That is, for base x and for a value y, 


y= logs) 


The properties of logarithms include 


log,(1) = 0 

log,(x) = 1 
log,(yz) = log,(y) + log,(z) (8.11) 
log.(y") = r X log,(y) (8.12) 


Consider a primitive root a for some prime number p (the argument can be 
developed for nonprimes as well). Then we know that the powers of a from 1 
through (p — 1) produce each integer from 1 through (p — 1) exactly once. We also 
know that any integer 5 satisfies 


b=r(modp) forsomer, where0 = r S (p — 1) 


by the definition of modular arithmetic. It follows that for any integer b and a prim- 
itive root a of prime number p, we can find a unique exponent i such that 


b =a'(modp) where0 =i <= (p — 1) 
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This exponent / is referred to as the discrete logarithm of the number 5 for the base 
a (mod p). We denote this value as dlog,, »(b).'° 
Note the following: 


dlog,,(1) = 0 because a” mod p = 1 mod p = 1 (8.13) 
dlog,,(a) = 1 because a’ mod p = a (8.14) 
Here is an example using a nonprime modulus, n = 9. Here ¢(n) = 6 and 
a = 2 is a primitive root. We compute the various powers of a and find 
22=1 2*=7(mod9) 
2 — 22 = 5 (mod9) 


2=4 2°=1(mod 9) 


P= k 


This gives us the following table of the numbers with given discrete logarithms 
(mod 9) for the root a = 2: 


Logarithm 0 1 2 3 4 5 
Number i 2 4 8 YF 3 


To make it easy to obtain the discrete logarithms of a given number, we 
rearrange the table: 


Number il 2a 7 & 
Logarithm 0 1 2 5 4 3 


Now consider 
x = a") mod py = al!&( mod p 
sy = qhlo8ap(*y) mod p 


Using the rules of modular multiplication, 


xy mod p = [(x mod p)(y mod p)]mod p 


a8) mod p = [(attoeo mod p) (atloeio) mod p)| mod p 


= (a8. (2) +dlog. p(y) ) mod p 


But now consider Euler’s theorem, which states that, for every a and n that are 
relatively prime, 


a® = 1 (mod n) 


10Many texts refer to the discrete logarithm as the index. There is no generally agreed notation for this 
concept, much less an agreed name. 
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Any positive integer z can be expressed in the form z = q + kd(n), with 
0 = q < d(n). Therefore, by Euler’s theorem, 


a = a‘(mod n) if z = qmod d(n) 


Applying this to the foregoing equality, we have 
dlog, (xy) = [dlog,.)(x) + dlog, »(y)](mod¢(p)) 


and generalizing, 


dlog,,,(y") = [r x dlog, p(y)](mod $(p)) 


This demonstrates the analogy between true logarithms and discrete logarithms. 
Keep in mind that unique discrete logarithms mod m to some base a exist only 
if ais a primitive root of m. 
Table 8.4, which is directly derived from Table 8.3, shows the sets of discrete 
logarithms that can be defined for modulus 19. 


Tables of Discrete Logarithms, Modulo 19 


(a) Discrete logarithms to the base 2, modulo 19 


1og2,0(a) 


a 


1ogs0(a) 


a 


logio19(@) 


a 


10g13,19(@) 


a 


logi419(@) 


a 


1ogi5,19(@) 
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Calculation of Discrete Logarithms 


Consider the equation 

y = g'mod p 
Given g, x, and p, it is a straightforward matter to calculate y. At the worst, we must 
perform x repeated multiplications, and algorithms exist for achieving greater effi- 
ciency (see Chapter 9). 

However, given y, g, and p, it is, in general, very difficult to calculate x (take the 
discrete logarithm). The difficulty seems to be on the same order of magnitude as 
that of factoring primes required for RSA. At the time of this writing, the asymptoti- 
cally fastest known algorithm for taking discrete logarithms modulo a prime number 
is on the order of [BETH91]: 

e (in p)'*(In(in p))?")) 


which is not feasible for large primes. 


8.6 RECOMMENDED READING AND WEB SITE 


There are many basic texts on the subject of number theory that provide far more detail than 
most readers of this book will desire. An elementary but nevertheless useful short introduction 
is [ORE67]. For the reader interested in a more in-depth treatment, two excellent textbooks 
on the subject are [KUMA98] and [ROSE0S5]. [LEVE90] is a readable and detailed account as 
well. All of these books include problems with solutions, enhancing their value for self-study. 

For readers willing to commit the time, perhaps the best way to get a solid grasp of the 
fundamentals of number theory is to work their way through [BURN97], which consists 
solely of a series of exercises with solutions that lead the student step-by-step through the 
concepts of number theory; working through all of the exercises is equivalent to completing 
an undergraduate course in number theory. 


BURN97_ Burn, R. A Pathway to Number Theory. Cambridge, England: Cambridge 
University Press, 1997. 


KUMA98_ Kumanduri, R., and Romero, C. Number Theory with Computer Applications. 
Upper Saddle River, NJ: Prentice Hall, 1998. 


LEVE90_ Leveque, W. Elementary Theory of Numbers. New York: Dover, 1990. 


ORE67 Ore, O. Invitation to Number Theory. Washington, D.C.: The Mathematical 
Association of America, 1967. 


ROSE05 Rosen, K. Elementary Number Theory and its Applications. Reading, MA: 
Addison-Wesley, 2000. 


Recommended Web Site: 


e The Prime Pages: Prime number research, records, and resources. 
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8.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


bijection 


Euler’s theorem order 


composite number Euler’s totient function prime number 


Chinese remainder theorem Fermat’s theorem primitive root 
discrete logarithm index 


Review Questions 


8.1 
8.2 
8.3 
8.4 


8.5 
8.6 


What is a prime number? 
What is the meaning of the expression a divides b? 
What is Euler’s totient function? 


The Miller-Rabin test can determine if a number is not prime but cannot determine if 
a number is prime. How can such an algorithm be used to test for primality? 


What is a primitive root of a number? 
What is the difference between an index and a discrete logarithm? 


Problems 


8.1 


8.2 


8.3 
8.4 
8.5 


8.6 


8.7 


The purpose of this problem is to determine how many prime numbers there are. 

Suppose there are a total of m prime numbers, and we list these in order: 

Pi =2< po =3< px =5<... < Dy. 

a. Define X = 1+ p; po... p,.That is, X is equal to one plus the product of all the 
primes. Can we find a prime number P,, that divides X? 

b. What can you say about m? 

c. Deduce that the total number of primes cannot be finite. 

d. Show that P,4; = 1+ py po... Dn. 

The purpose of this problem is to demonstrate that the probability that two random 

numbers are relatively prime is about 0.6. 


a. Let P = Pr[ged(a,b) = 1]. Show that P = Pr[gcd(a,b) = d] = Pld’. Hint: 


b 
Consider the quantity gcd (s 7? 7) 
b. The sum of the result of part (a) over all possible values of d is 1. That is 


>“ 'Pr[ged(a, oS = d\= = 1. Use this equality to determine the value of P. Hint: 

Use the identity De - 7, 
Why is ged(n, n + 1) = = 1 for two consecutive integers n andn + 1? 
Using Fermat’s theorem, find 3°! mod 11. 


Use Fermat’s theorem to find a number a between 0 and 72 with a congruent to 9794 
modulo 73. 

Use Fermat’s theorem to find a number x between 0 and 28 with x* congruent to 6 
modulo 29. (You should not need to use any brute-force searching.) 

Use Euler’s theorem to find a number a between 0 and 9 such that a is congruent to 
modulo 10. (Note: This is the same as the last digit of the decimal expansion of 7!°°.) 


71000 


264 CHAPTER 8 / INTRODUCTION TO NUMBER THEORY 


8.8 


8.9 


8.13 


8.14 


8.15 


8.16 


8.17 


Use Euler’s theorem to find a number x between 0 and 28 with x* congruent to 6 
modulo 35. (You should not need to use any brute-force searching.) 
Notice in Table 8.2 that (7) is even for n > 2. This is true for all n > 2. Give a con- 
cise argument why this is so. 
Prove the following: If p is prime, then #(p') = p' — p' '. Hint: What numbers have a 
factor in common with p’? 
It can be shown (see any book on number theory) that if gcd(m,n) = 1 then 
o(mn) = o(m)d(n). Using this property, the property developed in the preceding 
problem, and the property that ¢(p) = p — 1 for p prime, it is straightforward to 
determine the value of ¢(7) for any n. Determine the following: 
a. (41) b. 6(27) © (231) d. (440) 
It can also be shown that for arbitrary positive integer a, h(a) is given by 

t 


o(a) = [Pp (: - 1) 


i=1 


where a is given by Equation (8.1), namely: a = Pf! Pf... Pi. Demonstrate this 

result. 

Consider the function: f(m) = number of elements in the set 

{a:0 = a < nand ged(a, n) = 1}. What is this function? 

Although ancient Chinese mathematicians did good work coming up with their 

remainder theorem, they did not always get it right. They had a test for primality. The 

test said that n is prime if and only if n divides (2” — 2). 

a. Give an example that satisfies the condition using an odd prime. 

b. The condition is obviously true for n = 2. Prove that the condition is true if” is an 
odd prime (proving the if condition) 

c. Give an example of an odd n that is not prime and that does not satisfy the condition. 
You can do this with nonprime numbers up to a very large value. This misled the 
Chinese mathematicians into thinking that if the condition is true then n is prime. 

d. Unfortunately, the ancient Chinese never tried n = 341, which is nonprime 
(341 = 11 x 31), yet 341 divides 2*! — 2 without remainder. Demonstrate that 
2341 = 2 (mod 341) (disproving the only if condition). Hint: It is not necessary to 
calculate 2*"'; play around with the congruences instead. 


Show that, if 7 is an odd composite integer, then the Miller-Rabin test will return 
inconclusive fora = 1 anda = (n — 1). 

If n is composite and passes the Miller-Rabin test for the base a, then n is called 
a strong pseudoprime to the base a. Show that 2047 is a strong pseudoprime to 
the base 2. 


A common formulation of the Chinese remainder theorem (CRT) is as follows: Let 


m,, ...,m, be integers that are pairwise relatively prime for 1 = i,j = k, andi + j. 
Define M to be the product of all the m;’s. Let a), ..., a, be integers. Then the set of 
congruences: 


x = a,(mod m,) 


x = a,(mod mm) 


& 
Ill 


a,(mod Mk) 


has a unique solution modulo M. Show that the theorem stated in this form is true. 


8.18 


8.19 
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The example used by Sun-Tsu to illustrate the CRT was 
x = 2 (mod 3); x = 3 (mod 5); x = 2 (mod 7) 


Solve for x. 

Six professors begin courses on Monday, Tuesday, Wednesday, Thursday, Friday, and 
Saturday, respectively, and announce their intentions of lecturing at intervals of 2,3, 4, 
1,6, and 5 days, respectively. The regulations of the university forbid Sunday lectures 
(so that a Sunday lecture must be omitted). When first will all six professors find 
themselves compelled to omit a lecture? Hint: Use the CRT. 

Find all primitive roots of 25. 

Given 2 as a primitive root of 29, construct a table of discrete logarithms, and use it to 
solve the following congruences. 

a. 17x” = 10 (mod 29) 

b. x? — 4x — 16 = 0 (mod 29) 

c. x’ = 17 (mod 29) 


Programming Problems 


8.22 


8.23 


Write a computer program that implements fast exponentiation (successive squaring) 
modulo n. 

Write a computer program that implements the Miller-Rabin algorithm for a user- 
specified n. The program should allow the user two choices: (1) specify a possible 
witness a to test using the Witness procedure or (2) specify a number s of random 
witnesses for the Miller-Rabin test to check. 


CHAPTER 


PUBLIC-KEY CRYPTOGRAPHY 
AND RSA 


9.1 Principles of Public-Key Cryptosystems 


Public-Key Cryptosystems 

Applications for Public-Key Cryptosystems 
Requirements for Public-Key Cryptography 
Public-Key Cryptanalysis 


9.2 The RSA Algorithm 


Description of the Algorithm 
Computational Aspects 
The Security of RSA 


9.3 Recommended Reading and Web Site 

9.4 Key Terms, Review Questions, and Problems 
Appendix 9A Proof of the RSA Algorithm 
Appendix 9B The Complexity of Algorithms 


266 


9.1 / PRINCIPLES OF PUBLIC-KEY CRYPTOSYSTEMS 267 


Every Egyptian received two names, which were known respectively as the true 
name and the good name, or the great name and the little name; and while the 
good or little name was made public, the true or great name appears to have been 
carefully concealed. 


—The Golden Bough, Sir James George Frazer 


KEY POINTS 


® Asymmetric encryption is a form of cryptosystem in which encryption 
and decryption are performed using the different keys—one a public key 
and one a private key. It is also known as public-key encryption. 


® Asymmetric encryption transforms plaintext into ciphertext using a one of 
two keys and an encryption algorithm. Using the paired key and a decryp- 
tion algorithm, the plaintext is recovered from the ciphertext. 

® Asymmetric encryption can be used for confidentiality, authentication, 
or both. 

® The most widely used public-key cryptosystem is RSA. The difficulty of 
attacking RSA is based on the difficulty of finding the prime factors of a com- 
posite number. 


The development of public-key cryptography is the greatest and perhaps the only 
true revolution in the entire history of cryptography. From its earliest beginnings 
to modern times, virtually all cryptographic systems have been based on the ele- 
mentary tools of substitution and permutation. After millennia of working with 
algorithms that could be calculated by hand, a major advance in symmetric crypto- 
graphy occurred with the development of the rotor encryption/decryption machine. 
The electromechanical rotor enabled the development of fiendishly complex cipher 
systems. With the availability of computers, even more complex systems were 
devised, the most prominent of which was the Lucifer effort at IBM that culminated 
in the Data Encryption Standard (DES). But both rotor machines and DES, 
although representing significant advances, still relied on the bread-and-butter tools 
of substitution and permutation. 

Public-key cryptography provides a radical departure from all that has gone 
before. For one thing, public-key algorithms are based on mathematical functions 
rather than on substitution and permutation. More important, public-key cryptography 
is asymmetric, involving the use of two separate keys, in contrast to symmetric encryp- 
tion, which uses only one key. The use of two keys has profound consequences in the 
areas of confidentiality, key distribution, and authentication, as we shall see. 

Before proceeding, we should mention several common misconceptions con- 
cerning public-key encryption. One such misconception is that public-key encryption is 
more secure from cryptanalysis than is symmetric encryption. In fact, the security of 
any encryption scheme depends on the length of the key and the computational work 
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involved in breaking a cipher. There is nothing in principle about either symmetric or 
public-key encryption that makes one superior to another from the point of view of 
resisting cryptanalysis. 

A second misconception is that public-key encryption is a general-purpose tech- 
nique that has made symmetric encryption obsolete. On the contrary, because of the 
computational overhead of current public-key encryption schemes, there seems no 
foreseeable likelihood that symmetric encryption will be abandoned. As one of the 
inventors of public-key encryption has put it [DIFF88], “the restriction of public-key 
cryptography to key management and signature applications is almost universally 
accepted.” 

Finally, there is a feeling that key distribution is trivial when using public-key 
encryption, compared to the rather cumbersome handshaking involved with key distri- 
bution centers for symmetric encryption. In fact, some form of protocol is needed, 
generally involving a central agent, and the procedures involved are not simpler nor 
any more efficient than those required for symmetric encryption (e.g., see analysis in 
[NEED78]}). 

This chapter and the next provide an overview of public-key cryptography. First, 
we look at its conceptual framework. Interestingly, the concept for this technique was 
developed and published before it was shown to be practical to adopt it. Next, we 
examine the RSA algorithm, which is the most important encryption/decryption algo- 
rithm that has been shown to be feasible for public-key encryption. Other important 
public-key cryptographic algorithms are covered in Chapter 10. 

Much of the theory of public-key cryptosystems is based on number theory. If 
one is prepared to accept the results given in this chapter, an understanding of number 
theory is not strictly necessary. However, to gain a full appreciation of public-key 
algorithms, some understanding of number theory is required. Chapter 8 provides the 
necessary background in number theory. 

Table 9.1 defines some key terms. 


Table 9.1 Terminology Related to Asymmetric Encryption 


Asymmetric Keys 
Two related keys, a public key and a private key, that are used to perform complementary operations, such as 
encryption and decryption or signature generation and signature verification. 


Public Key Certificate 

A digital document issued and digitally signed by the private key of a Certification Authority that binds the 
name of a subscriber to a public key. The certificate indicates that the subscriber identified in the certificate has 
sole control and access to the corresponding private key. 


Public Key (Asymmetric) Cryptographic Algorithm 
A cryptographic algorithm that uses two related keys, a public key and a private key. The two keys have the 
property that deriving the private key from the public key is computationally infeasible. 


Public Key Infrastructure (PKI) 

A set of policies, processes, server platforms, software and workstations used for the purpose of administer- 
ing certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key 
certificates. 


Source: Glossary of Key Information Security Terms, NIST IR 7298 [KISS06] 
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9.1 PRINCIPLES OF PUBLIC-KEY CRYPTOSYSTEMS 


The concept of public-key cryptography evolved from an attempt to attack two of 
the most difficult problems associated with symmetric encryption. The first problem 
is that of key distribution, which is examined in some detail in Chapter 14. 

As Chapter 14 discusses, key distribution under symmetric encryption requires 
either (1) that two communicants already share a key, which somehow has been dis- 
tributed to them; or (2) the use of a key distribution center. Whitfield Diffie, one of 
the discoverers of public-key encryption (along with Martin Hellman, both at 
Stanford University at the time), reasoned that this second requirement negated the 
very essence of cryptography: the ability to maintain total secrecy over your own 
communication. As Diffie put it [DIFF88], “what good would it do after all to 
develop impenetrable cryptosystems, if their users were forced to share their keys 
with a KDC that could be compromised by either burglary or subpoena?” 

The second problem that Diffie pondered, and one that was apparently 
unrelated to the first, was that of digital signatures. If the use of cryptography was 
to become widespread, not just in military situations but for commercial and 
private purposes, then electronic messages and documents would need the equiv- 
alent of signatures used in paper documents. That is, could a method be devised 
that would stipulate, to the satisfaction of all parties, that a digital message had 
been sent by a particular person? This is a somewhat broader requirement than 
that of authentication, and its characteristics and ramifications are explored in 
Chapter 13. 

Diffie and Hellman achieved an astounding breakthrough in 1976 
[DIFF76 a, b] by coming up with a method that addressed both problems and was 
radically different from all previous approaches to cryptography, going back over 
four millennia.' 

In the next subsection, we look at the overall framework for public-key cryp- 
tography. Then we examine the requirements for the encryption/decryption algo- 
rithm that is at the heart of the scheme. 


Public-Key Cryptosystems 


Asymmetric algorithms rely on one key for encryption and a different but related 
key for decryption. These algorithms have the following important characteristic. 


e It is computationally infeasible to determine the decryption key given only 
knowledge of the cryptographic algorithm and the encryption key. 


'Diffie and Hellman first publicly introduced the concepts of public-key cryptography in 1976. Hellman 
credits Merkle with independently discovering the concept at that same time, although Merkle did not 
publish until 1978 [MERK78a]. In fact, the first unclassified document describing public-key distribution 
and public-key cryptography was a 1974 project proposal by Merkle (http://merkle.com/1974). However, 
this is not the true beginning. Admiral Bobby Inman, while director of the National Security Agency 
(NSA), claimed that public-key cryptography had been discovered at NSA in the mid-1960s [SIMM93]. 
The first documented introduction of these concepts came in 1970, from the Communications-Electronics 
Security Group, Britain’s counterpart to NSA, in a classified report by James Ellis [ELLI70]. Ellis 
referred to the technique as nonsecret encryption and describes the discovery in [ELLI99]. 
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In addition, some algorithms, such as RSA, also exhibit the following characteristic. 


e Either of the two related keys can be used for encryption, with the other used 
for decryption. 


A public-key encryption scheme has six ingredients (Figure 9.1a; compare 
with Figure 2.1). 
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Figure 9.1 Public-Key Cryptography 
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e Plaintext: This is the readable message or data that is fed into the algorithm as 
input. 

e Encryption algorithm: The encryption algorithm performs various transfor- 
mations on the plaintext. 


e Public and private keys: This is a pair of keys that have been selected so that if 
one is used for encryption, the other is used for decryption. The exact transfor- 
mations performed by the algorithm depend on the public or private key that 
is provided as input. 

e Ciphertext: This is the scrambled message produced as output. It depends on 
the plaintext and the key. For a given message, two different keys will produce 
two different ciphertexts. 


¢ Decryption algorithm: This algorithm accepts the ciphertext and the matching 
key and produces the original plaintext. 


The essential steps are the following. 


1. Each user generates a pair of keys to be used for the encryption and decryp- 
tion of messages. 


n 


Each user places one of the two keys in a public register or other accessible file. 
This is the public key. The companion key is kept private. As Figure 9.1a suggests, 
each user maintains a collection of public keys obtained from others. 


3. If Bob wishes to send a confidential message to Alice, Bob encrypts the message 
using Alice’s public key. 

4. When Alice receives the message, she decrypts it using her private key. No 
other recipient can decrypt the message because only Alice knows Alice’s 
private key. 


With this approach, all participants have access to public keys, and private 
keys are generated locally by each participant and therefore need never be distrib- 
uted. As long as a user’s private key remains protected and secret, incoming com- 
munication is secure. At any time, a system can change its private key and publish 
the companion public key to replace its old public key. 

Table 9.2 summarizes some of the important aspects of symmetric and public- 
key encryption. To discriminate between the two, we refer to the key used in sym- 
metric encryption as a secret key. The two keys used for asymmetric encryption 
are referred to as the public key and the private key.” Invariably, the private key is 
kept secret, but it is referred to as a private key rather than a secret key to avoid 
confusion with symmetric encryption. 

Let us take a closer look at the essential elements of a public-key encryption 
scheme, using Figure 9.2 (compare with Figure 2.2). There is some source A that 


The following notation is used consistently throughout. A secret key is represented by K,,, where m is 
some modifier; for example, K, is a secret key owned by user A. A public key is represented by PU,, for 
user A, and the corresponding private key is PR,. Encryption of plaintext X can be performed with a 
secret key, a public key, or a private key, denoted by E(K,, X), E(PU,, X), and E(PR,, X), respectively. 
Similarly, decryption of ciphertext C can be performed with a secret key, a public key, or a private key, 
denoted by D(K,, X), D(PU,, X), and D(PR,, X), respectively. 
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Table 9.2 Conventional and Public-Key Encryption 


Conventional Encryption Public-Key Encryption 


Needed to Work: Needed to Work: 


1. The same algorithm with the same key is used 1. One algorithm is used for encryption and 

for encryption and decryption. decryption with a pair of keys, one for encryption 
2. The sender and receiver must share the and one for decryption. 

algorithm and the key. 2. The sender and receiver must each have one of 


the matched pair of keys (not the same one). 
Needed for Security: 


Needed for Security: 
1. The key must be kept secret. 


2. It must be impossible or at least impractical 1. One of the two keys must be kept secret. 
to decipher a message if no other information 2. It must be impossible or at least impractical 
is available. to decipher a message if no other information 


. Knowledge of the algorithm plus samples of is available. 
ciphertext must be insufficient to determine 3. Knowledge of the algorithm plus one of the keys 
the key. plus samples of ciphertext must be insufficient 
to determine the other key. 


produces a message in plaintext, X = |X, X>, ..., Xj]. The M elements of X are 
letters in some finite alphabet. The message is intended for destination B. B gener- 
ates a related pair of keys: a public key, PU,, and a private key, PR,. PR, is known 
only to B, whereas PU, is publicly available and therefore accessible by A. 

With the message X and the encryption key PU, as input, A forms the 
ciphertext Y=[Y 1, Yo, ..., Yn: 


Y=E(PUp, X) 
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Figure 9.2 Public-Key Cryptosystem: Secrecy 
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The intended receiver, in possession of the matching private key, is able to invert the 
transformation: 


X=D(PRz, Y) 


An adversary, observing Y and having access to PU;, but not having access to PR, 
or X, must attempt to recover XY and/or PR». It is assumed that the adversary does 
have knowledge of the encryption (E) and decryption (D) algorithms. If the adver- 
sary is interested only in this particular message, then the focus of effort is to 
recover X by generating a plaintext estimate X. Often, however, the adversary is 
interested in being able to read future messages as well, in which case an attempt is 
made to recover PR, by generating an estimate PR,. 

We mentioned earlier that either of the two related keys can be used for 
encryption, with the other being used for decryption. This enables a rather different 
cryptographic scheme to be implemented. Whereas the scheme illustrated in 
Figure 9.2 provides confidentiality, Figures 9.1b and 9.3 show the use of public-key 
encryption to provide authentication: 


Y=E(PR,,X) 
X=D(PU,, Y) 


In this case, A prepares a message to B and encrypts it using A’s private key 
before transmitting it. B can decrypt the message using A’s public key. Because the 
message was encrypted using A’s private key, only A could have prepared the 
message. Therefore, the entire encrypted message serves as a digital signature. In 
addition, it is impossible to alter the message without access to A’s private key, so 
the message is authenticated both in terms of source and in terms of data integrity. 
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Figure 9.3. Public-Key Cryptosystem: Authentication 
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In the preceding scheme, the entire message is encrypted, which, although 
validating both author and contents, requires a great deal of storage. Each docu- 
ment must be kept in plaintext to be used for practical purposes. A copy also must 
be stored in ciphertext so that the origin and contents can be verified in case of a 
dispute. A more efficient way of achieving the same results is to encrypt a small 
block of bits that is a function of the document. Such a block, called an authentica- 
tor, must have the property that it is infeasible to change the document without 
changing the authenticator. If the authenticator is encrypted with the sender’s 
private key, it serves as a signature that verifies origin, content, and sequencing. 
Chapter 13 examines this technique in detail. 

It is important to emphasize that the encryption process depicted in Figures 9.1b 
and 9.3 does not provide confidentiality. That is, the message being sent is safe from 
alteration but not from eavesdropping. This is obvious in the case of a signature based 
on a portion of the message, because the rest of the message is transmitted in the 
clear. Even in the case of complete encryption, as shown in Figure 9.3, there is no 
protection of confidentiality because any observer can decrypt the message by using 
the sender’s public key. 

It is, however, possible to provide both the authentication function and confi- 
dentiality by a double use of the public-key scheme (Figure 9.4): 


Z=E(PUp, E(PRy, X)) 
X = D(PU;, D(PR», Z)) 


In this case, we begin as before by encrypting a message, using the sender’s private 
key. This provides the digital signature. Next, we encrypt again, using the receiver’s 
public key. The final ciphertext can be decrypted only by the intended receiver, 
who alone has the matching private key. Thus, confidentiality is provided. The 
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Figure 9.4 Public-Key Cryptosystem: Authentication and Secrecy 
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disadvantage of this approach is that the public-key algorithm, which is complex, 
must be exercised four times rather than two in each communication. 


Applications for Public-Key Cryptosystems 


Before proceeding, we need to clarify one aspect of public-key cryptosystems that is 
otherwise likely to lead to confusion. Public-key systems are characterized by 
the use of a cryptographic algorithm with two keys, one held private and one avail- 
able publicly. Depending on the application, the sender uses either the sender’s 
private key or the receiver’s public key, or both, to perform some type of crypto- 
graphic function. In broad terms, we can classify the use of public-key cryptosystems 
into three categories 


e Encryption/decryption: The sender encrypts a message with the recipient’s 
public key. 

e Digital signature: The sender “signs” a message with its private key. Signing is 
achieved by a cryptographic algorithm applied to the message or to a small 
block of data that is a function of the message. 


e Key exchange: Two sides cooperate to exchange a session key. Several different 
approaches are possible, involving the private key(s) of one or both parties. 


Some algorithms are suitable for all three applications, whereas others can be 
used only for one or two of these applications. Table 9.3 indicates the applications 
supported by the algorithms discussed in this book. 


Requirements for Public-Key Cryptography 


The cryptosystem illustrated in Figures 9.2 through 9.4 depends on a cryptographic 
algorithm based on two related keys. Diffie and Hellman postulated this system 
without demonstrating that such algorithms exist. However, they did lay out the 
conditions that such algorithms must fulfill [DIFF76b]. 


1. It is computationally easy for a party B to generate a pair (public key PU, 
private key PR;,). 


WN 


. It is computationally easy for a sender A, knowing the public key and the 
message to be encrypted, M, to generate the corresponding ciphertext: 


C=E(PU;, M) 


Table 9.3 Applications for Public-Key Cryptosystems 


Algorithm Encryption/ Decryption Digital Signature Key Exchange 
Elliptic Curve Yes 
Diffie-Hellman No 
DSS No Yes No 
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3. It is computationally easy for the receiver B to decrypt the resulting ciphertext 
using the private key to recover the original message: 


M=D(PRz», C) = D[PRp, E(PUp, M)] 


4. It is computationally infeasible for an adversary, knowing the public key, PU,, to 
determine the private key, PR». 


5. It is computationally infeasible for an adversary, knowing the public key, PU), 
and a ciphertext, C, to recover the original message, M. 


We can add a sixth requirement that, although useful, is not necessary for all 
public-key applications: 


6. The two keys can be applied in either order: 
M=D[PU), E(PR», M)] = D[PRp, E(PUp, M)] 


These are formidable requirements, as evidenced by the fact that only a few 
algorithms (RSA, elliptic curve cryptography, Diffie-Hellman, DSS) have received 
widespread acceptance in the several decades since the concept of public-key cryp- 
tography was proposed. 

Before elaborating on why the requirements are so formidable, let us first 
recast them. The requirements boil down to the need for a trap-door one-way func- 
tion. A one-way function® is one that maps a domain into a range such that every 
function value has a unique inverse, with the condition that the calculation of the 
function is easy, whereas the calculation of the inverse is infeasible: 


Y = f(X) easy 
X =f '(Y) infeasible 


Generally, easy is defined to mean a problem that can be solved in polynomial 
time as a function of input length. Thus, if the length of the input is 7 bits, then the 
time to compute the function is proportional to n“, where a is a fixed constant. Such 
algorithms are said to belong to the class P. The term infeasible is a much fuzzier 
concept. In general, we can say a problem is infeasible if the effort to solve it grows 
faster than polynomial time as a function of input size. For example, if the length of 
the input is n bits and the time to compute the function is proportional to 2”, the 
problem is considered infeasible. Unfortunately, it is difficult to determine if a 
particular algorithm exhibits this complexity. Furthermore, traditional notions of 
computational complexity focus on the worst-case or average-case complexity of an 
algorithm. These measures are inadequate for cryptography, which requires that it 
be infeasible to invert a function for virtually all inputs, not for the worst case or 
even average case. A brief introduction to some of these concepts is provided in 
Appendix 9B. 


3Not to be confused with a one-way hash function, which takes an arbitrarily large data field as its 
argument and maps it to a fixed output. Such functions are used for authentication (see Chapter 11). 
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We now turn to the definition of a trap-door one-way function, which is easy to 
calculate in one direction and infeasible to calculate in the other direction unless 
certain additional information is known. With the additional information the 
inverse can be calculated in polynomial time. We can summarize as follows: A trap- 
door one-way function is a family of invertible functions f,, such that 


Y =f,(X) _ easy, if k and X are known 
X = f,'(Y)_ easy, if k and Y are known 
X ={,'(Y)_ infeasible, if Y is known but k is not known 


Thus, the development of a practical public-key scheme depends on discovery of a 
suitable trap-door one-way function. 


Public-Key Cryptanalysis 


As with symmetric encryption, a public-key encryption scheme is vulnerable to a 
brute-force attack. The countermeasure is the same: Use large keys. However, there 
is a tradeoff to be considered. Public-key systems depend on the use of some sort of 
invertible mathematical function. The complexity of calculating these functions may 
not scale linearly with the number of bits in the key but grow more rapidly than that. 
Thus, the key size must be large enough to make brute-force attack impractical but 
small enough for practical encryption and decryption. In practice, the key sizes 
that have been proposed do make brute-force attack impractical but result in 
encryption/decryption speeds that are too slow for general-purpose use. Instead, 
as was mentioned earlier, public-key encryption is currently confined to key man- 
agement and signature applications. 

Another form of attack is to find some way to compute the private key given 
the public key. To date, it has not been mathematically proven that this form of 
attack is infeasible for a particular public-key algorithm. Thus, any given algorithm, 
including the widely used RSA algorithm, is suspect. The history of cryptanalysis 
shows that a problem that seems insoluble from one perspective can be found to 
have a solution if looked at in an entirely different way. 

Finally, there is a form of attack that is peculiar to public-key systems. This is, 
in essence, a probable-message attack. Suppose, for example, that a message were 
to be sent that consisted solely of a 56-bit DES key. An adversary could encrypt all 
possible 56-bit DES keys using the public key and could discover the encrypted 
key by matching the transmitted ciphertext. Thus, no matter how large the key size 
of the public-key scheme, the attack is reduced to a brute-force attack on a 56-bit 
key. This attack can be thwarted by appending some random bits to such simple 
messages. 


9.2 THE RSA ALGORITHM 


The pioneering paper by Diffie and Hellman [DIFF76b] introduced a new approach 
to cryptography and, in effect, challenged cryptologists to come up with a crypto- 
graphic algorithm that met the requirements for public-key systems. A number of 
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algorithms have been proposed for public-key cryptography. Some of these, though 
initially promising, turned out to be breakable.* 

One of the first successful responses to the challenge was developed in 1977 by 
Ron Rivest, Adi Shamir, and Len Adleman at MIT and first published in 1978 
[RIVE78].° The Rivest-Shamir-Adleman (RSA) scheme has since that time reigned 
supreme as the most widely accepted and implemented general-purpose approach 
to public-key encryption. 

The RSA scheme is a block cipher in which the plaintext and ciphertext are 
integers between 0 and n — 1 for some n. A typical size for n is 1024 bits, or 309 dec- 
imal digits. That is, n is less than 2!9*4, We examine RSA in this section in some 
detail, beginning with an explanation of the algorithm. Then we examine some of 
the computational and cryptanalytical implications of RSA. 


Description of the Algorithm 


RSA makes use of an expression with exponentials. Plaintext is encrypted in 
blocks, with each block having a binary value less than some number n. That is, the 
block size must be less than or equal to log.(m) + 1; in practice, the block size is i 
bits, where 2' <n < 2'*!. Encryption and decryption are of the following form, for 
some plaintext block M and ciphertext block C. 


C = M’ modn 
M = Cémodn = (M°) modn = M® mod n 
Both sender and receiver must know the value of n. The sender knows the 
value of e, and only the receiver knows the value of d. Thus, this is a public-key 
encryption algorithm with a public key of PU= {e, n} and a private key of PR = {d, n}. 
For this algorithm to be satisfactory for public-key encryption, the following require- 
ments must be met. 
1. It is possible to find values of e, d,n such that M“! mod n= M for all M <n. 
2. It is relatively easy to calculate M’ mod n and C“ mod n for all values of M <n. 
3. It is infeasible to determine d given e and n. 


For now, we focus on the first requirement and consider the other questions 
later. We need to find a relationship of the form 


M* modn=M 


The preceding relationship holds if e and d are multiplicative inverses modulo 
¢(n), where $(n) is the Euler totient function. It is shown in Chapter 8 that for p, 
q prime, ¢(pq) = (p — 1)(q — 1). The relationship between e and d can be 
expressed as 


ed mod @(n) =1 (9.1) 


4The most famous of the fallen contenders is the trapdoor knapsack proposed by Ralph Merkle. We 
describe this in Appendix J. 

> Apparently, the first workable public-key system for encryption/decryption was put forward by Clifford 
Cocks of Britain’s CESG in 1973 [COCK73]; Cocks’ method is virtually identical to RSA. 
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This is equivalent to saying 
ed = 1 mod d(n) 
d = e 'mod g(n) 


That is, e and d are multiplicative inverses mod ¢(n). Note that, according to the rules 
of modular arithmetic, this is true only if d (and therefore e) is relatively prime to 
(n). Equivalently, gcd(#(n), d) =1.See Appendix 9A for a proof that Equation (9.1) 
satisfies the requirement for RSA. 

We are now ready to state the RSA scheme. The ingredients are the following: 


P, q, two prime numbers (private, chosen) 
n=pq (public, calculated) 
e, with gcd((n), e) =1;1<e<(n) (public, chosen) 
d=e' (mod $(n)) (private, calculated) 


The private key consists of {d, n} and the public key consists of {e, n}. Suppose 
that user A has published its public key and that user B wishes to send the message 
M to A. Then B calculates C= M° mod v and transmits C. On receipt of this cipher- 
text, user A decrypts by calculating M = C4 mod n. 

Figure 9.5 summarizes the RSA algorithm. It corresponds to Figure 9.1a: Alice 
generates a public/private key pair; Bob encrypts using Alice’s public key; and Alice 
decrypts using her private key. An example from [SING99] is shown in Figure 9.6. 
For this example, the keys were generated as follows. 


1. Select two prime numbers, p = 17 and g = 11. 
. Calculate n= pg = 17 x 11 = 187. 
. Calculate d(n) = (p— 1)(q—-1) =16 x 10= 160. 


. Select e such that e is relatively prime to #(n) = 160 and less than (7); we 
choose e = 7. 


. Determine d such that de= 1 (mod 160) and d < 160. The correct value is d= 23, 
because 23 x 7 = 161 = (1 x 160) + 1; d can be calculated using the extended 
Euclid’s algorithm (Chapter 4). 


The resulting keys are public key PU = {7, 187} and private key PR = {23, 187}. 
The example shows the use of these keys for a plaintext input of M = 88. For encryp- 
tion, we need to calculate C = 88’ mod 187. Exploiting the properties of modular 
arithmetic, we can do this as follows. 


88’ mod 187 = [(88* mod 187) x (887 mod 187) 
x (88! mod 187)] mod 187 


88! mod 187 = 88 

88% mod 187 = 7744 mod 187 = 77 

88+ mod 187 = 59,969,536 mod 187 = 132 

887 mod 187 = (88 x 77 x 132) mod 187 = 894,432 mod 187 = 11 


Ww Nw 


Nn 


280 CHAPTER 9 / PUBLIC-KEY CRYPTOGRAPHY AND RSA 


Key Generation Alice 


Select p,q p and q both prime, p #q 
Calculate n =p X q 

Calcuate $(n) = (p—1)(q—-1) 

Select integer e gcd (f(n), e) =1;1 <e< d(n) 
Calculate d d=e'! (mod ¢(n)) 

Public key PU={e,n} 

Private key PR=({d,n} 


Encryption by Bob with Alice’s Public Key 


Plaintext: M<n 


Ciphertext: C=M* modn 


Decryption by Alice with Alice’s Public Key 


Ciphertext: Ee 
Plaintext: M=C%modn 


Figure 9.5 The RSA Algorithm 


Encryption Decryption 


. Ciphertext . 
Plaintext 11 Plaintext 


88 — TP it" fb 1PnoaG8= 88 + > 88 


/ I 
PU = 7, 187 PR = 23, 187 
Figure 9.6 Example of RSA Algorithm 


For decryption, we calculate M = 117* mod 187: 


1173 mod 187 = [(11! mod 187) x (11? mod 187) x (114 mod 187) 
x (118 mod 187) x (118 mod 187)] mod 187 


11! mod 187 = 11 

11? mod 187 = 121 

114 mod 187 = 14,641 mod 187 = 55 

118 mod 187 = 214,358,881 mod 187 = 33 

1173 mod 187 = (11 x 121 x 55 x 33 x 33) mod 187 = 79,720,245 mod 187 = 88 
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We now look at an example from [HELL79], which shows the use of RSA 
to process multiple blocks of data. In this simple example, the plaintext is an 
alphanumeric string. Each plaintext symbol is assigned a unique code of two 
decimal digits (e.g., a = 00, A = 26).° A plaintext block consists of four decimal 
digits, or two alphanumeric characters. Figure 9.7a illustrates the sequence 
of events for the encryption of multiple blocks, and Figure 9.7b gives a specific 
example. The circled numbers indicate the order in which operations are 


performed. 


Sender 


6) 


Plaintext P 


Decimal string 


Blocks of numbers 
[Pollo 00 


Ciphertext C 


C, =P,’ modn 
C, =P, mod n 


Transmit 


Recovered 
decimal text 
P,=C,/ modn 
P,=C,/ modn 


Private key 
d,n 
d=e" mod ¢(n) 
o(n) =(p-Dq-D 


® n=pq 
Random number 
generator 


(a) General approach 


Figure 9.7 RSA Processeing of Multiple Blocks 


Receiver 


Sender 


® 


P, = 3314 P,= 2262 P,=0017 
P,=0462 P,=2414 P, = 2066 


C, = 3314"! mod 11023 = 10260 
C, = 2262"! mod 11023 = 9489 
C, = 17" mod 11023 = 1782 

C, = 462"! mod 11023 = 727 

C, = 2414" mod 11023 = 10032 
C, = 2006"! mod 11023 = 2253 


Transmit 


P, = 102605! mod 11023 = 3314 
P, = 9489°°! mod 11023 = 2262 
P, = 17825"! mod 11023 = 0017 
5891 = 11-' mod 10800 P= 727! mod 11023 = 0462 
10800 = (73 -1)(151-1) | P, = 1003258! mod 11023 = 2414 


11023 = 73x51 P,, = 2253°"! mod 11023 = 2006 


Receiver 


Random number 
generator 


(b) Example 


°The complete mapping of alphanumeric characters to decimal digits is at this book’s Website in the 


document RSAexample.pdf. 
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Computational Aspects 


We now turn to the issue of the complexity of the computation required to use RSA. 
There are actually two issues to consider: encryption/decryption and key genera- 
tion. Let us look first at the process of encryption and decryption and then consider 
key generation. 


EXPONENTIATION IN MODULAR ARITHMETIC Both encryption and decryption in 
RSA involve raising an integer to an integer power, mod n. If the exponentiation is 
done over the integers and then reduced modulo n, the intermediate values would 
be gargantuan. Fortunately, as the preceding example shows, we can make use of a 
property of modular arithmetic: 


[((amodn) X (bmodn)] modn = (a X b) modn 


Thus, we can reduce intermediate results modulo n. This makes the calculation 
practical. 

Another consideration is the efficiency of exponentiation, because with RSA, 
we are dealing with potentially large exponents. To see how efficiency might be 
increased, consider that we wish to compute x!°. A straightforward approach 
requires 15 multiplications: 


x= yx aK XXXKKKKXKXKKKXKXKXHKXKXKXKXK 


However, we can achieve the same final result with only four multiplications if we 
repeatedly take the square of each partial result, successively forming (x”, x4, x8, x!*). 
As another example, suppose we wish to calculate x!! mod n for some integers x and 
n. Observe that x!! = x!*7*8 = (x)(x?)(x°). In this case, we compute x mod n, x? mod n, 
x‘ mod n, and .x* mod n and then calculate [(x mod ) x (x? mod n) x (x° mod n)] mod n. 

More generally, suppose we wish to find the value a? with a and m positive 


integers. If we express b as a binary number b;b;_;. . . bo, then we have 


b= 2 
B;#0 
Therefore, 
GA 
punter’ = Tha”? 
5;40 
a’mod n = [Ta |mod n= (T| «moa n} mod n 
b;#0 b,#0 


We can therefore develop the algorithm’ for computing a” mod n, shown in 
Figure 9.8. Table 9.4 shows an example of the execution of this algorithm. Note that 
the variable c is not needed; it is included for explanatory purposes. The final value 
of c is the value of the exponent. 


’The algorithm has a long history; this particular pseudocode expression is from [CORM04]. 
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c¢0; f£¢1 
for i<«< k downto 0 
do ¢i2 xX cc 
f< (f X £) modn 
if b =1 
thenc¢ ct 1 
1B xe (G2 2S el) inleyel Gal 


return f 


Note: The integer b is expressed as a 
binary number b;,b;,_—1... bo. 


Figure 9.8 Algorithm for Computing a? mod n 


EFFICIENT OPERATION USING THE PuBLic Key To speed up the operation of the 
RSA algorithm using the public key, a specific choice of e is usually made. The most 
common choice is 65537 (2'° + 1); two other popular choices are 3 and 17. Each of 
these choices has only two 1 bits, so the number of multiplications required to 
perform exponentiation is minimized. 

However, with a very small public key, such as e= 3, RSA becomes vulnerable 
to a simple attack. Suppose we have three different RSA users who all use the value 
e = 3 but have unique values of n, namely (1, m2, 13). If user A sends the same 
encrypted message M to all three users, then the three ciphertexts are C; = M* mod ny, 
C> = M? mod np, and C;= M? mod n3. It is likely that 11, 12, and n3 are pairwise rela- 
tively prime. Therefore, one can use the Chinese remainder theorem (CRT) to com- 
pute M? mod (n,n n3). By the rules of the RSA algorithm, M is less than each of the 
n;, therefore M? < njnon3. Accordingly, the attacker need only compute the cube 
root of M>. This attack can be countered by adding a unique pseudorandom bit 
string as padding to each instance of M to be encrypted. This approach is discussed 
subsequently. 

The reader may have noted that the definition of the RSA algorithm (Figure 9.5) 
requires that during key generation the user selects a value of e that is relatively prime 
to d(n). Thus, if a value of e is selected first and the primes p and q are generated, it may 
turn out that gcd((7), e) # 1. In that case, the user must reject the p, q values and 
generate a new p,q pair. 


Table 9.4 Result of the Fast Modular Exponentiation Algorithm for a’ mod n, where a= 7, 
b = 560 = 1000110000, and n = 561 
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EFFICIENT OPERATION USING THE PrivATE Key We cannot similarly choose a small 
constant value of d for efficient operation. A small value of d is vulnerable to a brute- 
force attack and to other forms of cryptanalysis [WIEN90]. However, there is a way to 
speed up computation using the CRT. We wish to compute the value M = C4 mod n. 
Let us define the following intermediate results: 

V, = C’modp V, = C‘mod q 


Following the CRT using Equation (8.8), define the quantities 
X, = 4X (q''modp) X, = p X (p_'mod q) 
The CRT then shows, using Equation (8.9), that 
M = (V,,X, + V,X,) mod n 


Furthermore, we can simplify the calculation of V, and V, using Fermat’s 
theorem, which states that a?~!=1 (mod p) if p and a are relatively prime. Some 
thought should convince you that the following are valid. 


V, = C’mod p = C47" ?~)) mod p V, = C'mod g = C4"! 4~)) mod q 


The quantities d mod (p — 1) and d mod (q — 1) can be precalculated. The end 
result is that the calculation is approximately four times as fast as evaluating M = C¢ 
mod n directly [BONE(02]. 


Key GENERATION Before the application of the public-key cryptosystem, each 
participant must generate a pair of keys. This involves the following tasks. 


e Determining two prime numbers, p and gq. 
e Selecting either e or d and calculating the other. 


First, consider the selection of p and g. Because the value of n = pq will be 
known to any potential adversary, in order to prevent the discovery of p and qg by 
exhaustive methods, these primes must be chosen from a sufficiently large set (i.e., p 
and q must be large numbers). On the other hand, the method used for finding large 
primes must be reasonably efficient. 

At present, there are no useful techniques that yield arbitrarily large primes, 
so some other means of tackling the problem is needed. The procedure that is 
generally used is to pick at random an odd number of the desired order of magni- 
tude and test whether that number is prime. If not, pick successive random numbers 
until one is found that tests prime. 

A variety of tests for primality have been developed (e.g., see [KNUT98] 
for a description of a number of such tests). Almost invariably, the tests are prob- 
abilistic. That is, the test will merely determine that a given integer is probably 
prime. Despite this lack of certainty, these tests can be run in such a way as to 
make the probability as close to 1.0 as desired. As an example, one of the more 
efficient and popular algorithms, the Miller-Rabin algorithm, is described in 
Chapter 8. With this algorithm and most such algorithms, the procedure for test- 
ing whether a given integer n is prime is to perform some calculation that 
involves n and a randomly chosen integer a. If n “fails” the test, then n is not 
prime. If n “passes” the test, then n may be prime or nonprime. If 1 passes many 
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such tests with many different randomly chosen values for a, then we can have 
high confidence that n is, in fact, prime. 
In summary, the procedure for picking a prime number is as follows. 


. Pick an odd integer n at random (e.g., using a pseudorandom number generator). 
. Pick an integer a <n at random. 


Qe oO = 


. Perform the probabilistic primality test, such as Miller-Rabin, with a as a parameter. 
If n fails the test, reject the value n and go to step 1. 


4. If n has passed a sufficient number of tests, accept n; otherwise, go to step 2. 


This is a somewhat tedious procedure. However, remember that this process is 
performed relatively infrequently: only when a new pair (PU, PR) is needed. 

It is worth noting how many numbers are likely to be rejected before a prime 
number is found. A result from number theory, known as the prime number theorem, 
states that the primes near N are spaced on the average one every (In N) integers. 
Thus, on average, one would have to test on the order of In(N) integers before a 
prime is found. Actually, because all even integers can be immediately rejected, the 
correct figure is In(N)/2. For example, if a prime on the order of magnitude of 27° 
were sought, then about In(2”°’)/2 = 70 trials would be needed to find a prime. 

Having determined prime numbers p and q, the process of key generation is 
completed by selecting a value of e and calculating d or, alternatively, selecting a 
value of d and calculating e. Assuming the former, then we need to select an e such 
that gcd(#(n), e) = 1 and then calculate d = e! (mod @(n)). Fortunately, there is a 
single algorithm that will, at the same time, calculate the greatest common divisor of 
two integers and, if the gcd is 1, determine the inverse of one of the integers modulo 
the other. The algorithm, referred to as the extended Euclid’s algorithm, is 
explained in Chapter 4. Thus, the procedure is to generate a series of random num- 
bers, testing each against (n) until a number relatively prime to (7) is found. 
Again, we can ask the question: How many random numbers must we test to find a 
usable number, that is, a number relatively prime to d(n)? It can be shown easily 
that the probability that two random numbers are relatively prime is about 0.6; thus, 
very few tests would be needed to find a suitable integer (see Problem 8.2). 


The Security of RSA 


Four possible approaches to attacking the RSA algorithm are 


e Brute force: This involves trying all possible private keys. 

e Mathematical attacks: There are several approaches, all equivalent in effort to 
factoring the product of two primes. 

e Timing attacks: These depend on the running time of the decryption algorithm. 


e Chosen ciphertext attacks: This type of attack exploits properties of the RSA 
algorithm. 


The defense against the brute-force approach is the same for RSA as for other 
cryptosystems, namely, to use a large key space. Thus, the larger the number of bits 
in d, the better. However, because the calculations involved, both in key generation 
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and in encryption/decryption, are complex, the larger the size of the key, the slower 
the system will run. 
In this subsection, we provide an overview of mathematical and timing attacks. 


THE FACTORING Prop_eM We can identify three approaches to attacking RSA 
mathematically. 


1. Factor n into its two prime factors. This enables calculation of #(n) = (p — 1) x 
(q—1), which in turn enables determination of d= e! (mod $(n)). 


nN 


. Determine ¢(n) directly, without first determining p and q. Again, this enables 
determination of d= e! (mod Q(n)). 


i) 


. Determine d directly, without first determining (7). 


Most discussions of the cryptanalysis of RSA have focused on the task of fac- 
toring 7 into its two prime factors. Determining ¢(n) given n is equivalent to factor- 
ing n [RIBE96]. With presently known algorithms, determining d given e and n 
appears to be at least as time-consuming as the factoring problem [KALI95]. Hence, 
we can use factoring performance as a benchmark against which to evaluate the 
security of RSA. 

For a large n with large prime factors, factoring is a hard problem, but it is not as 
hard as it used to be. A striking illustration of this is the following. In 1977, the three 
inventors of RSA dared Scientific American readers to decode a cipher they printed in 
Martin Gardner’s “Mathematical Games” column [GARD77]. They offered a $100 
reward for the return of a plaintext sentence, an event they predicted might not occur 
for some 40 quadrillion years. In April of 1994, a group working over the Internet 
claimed the prize after only eight months of work [LEUT94]. This challenge used a 
public key size (length of n) of 129 decimal digits, or around 428 bits. In the meantime, 
just as they had done for DES, RSA Laboratories had issued challenges for the RSA 
cipher with key sizes of 100, 110, 120, and so on, digits. The latest challenge to be met is 
the RSA-200 challenge with a key length of 200 decimal digits, or about 663 bits. 
Table 9.5 shows the results to date. The level of effort is measured in MIPS-years: a 


Table 9.5 Progress in Factorization 


Number of Approximate Date 
Decimal Digits | Number of Bits Achieved MIPS- Years Algorithm 


100 Boo, April 1991 Quadratic sieve 


110 365 April 1992 Quadratic sieve 
120 398 June 1993 Quadratic sieve 
April 1994 Quadratic sieve 


April 1996 Generalized number field sieve 


February 1999 Generalized number field sieve 


August 1999 Generalized number field sieve 


April 2003 Lattice sieve 


December 2003 Lattice sieve 


May 2005 Lattice sieve 
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million-instructions-per-second processor running for one year, which is about 3 x 10'° 
instructions executed. A 1 GHz Pentium is about a 250-MIPS machine. 

A striking fact about Table 9.5 concerns the method used. Until the mid-1990s, 
factoring attacks were made using an approach known as the quadratic sieve. The 
attack on RSA-130 used a newer algorithm, the generalized number field sieve 
(GNEFS), and was able to factor a larger number than RSA-129 at only 20% of the 
computing effort. 

The threat to larger key sizes is twofold: the continuing increase in computing 
power and the continuing refinement of factoring algorithms. We have seen that the 
move to a different algorithm resulted in a tremendous speedup. We can expect further 
refinements in the GNFS, and the use of an even better algorithm is also a possibility. 
In fact, a related algorithm, the special number field sieve (SNFS), can factor numbers 
with a specialized form considerably faster than the generalized number field sieve. 
Figure 9.9 compares the performance of the two algorithms. It is reasonable to expect a 
breakthrough that would enable a general factoring performance in about the same 
time as SNFS, or even better [ODLY95]. Thus, we need to be careful in choosing a key 
size for RSA. For the near future, a key size in the range of 1024 to 2048 bits seems 
reasonable. 

In addition to specifying the size of n,a number of other constraints have been 
suggested by researchers. To avoid values of n that may be factored more easily, the 
algorithm’s inventors suggest the following constraints on p and q. 

1. p and q should differ in length by only a few digits. Thus, for a 1024-bit key (309 

decimal digits), both p and q should be on the order of magnitude of 10° to 10. 

2. Both (p—1) and (q—1) should contain a large prime factor. 

3. gced(p — 1, q—1) should be small. 
In addition, it has been demonstrated that if e <n and d < n'4 
determined [WIEN90]. 


, then d can be easily 


Timinc ATi4cks If one needed yet another lesson about how difficult it is to assess 
the security of a cryptographic algorithm, the appearance of timing attacks provides 
a stunning one. Paul Kocher, a cryptographic consultant, demonstrated that a 
snooper can determine a private key by keeping track of how long a computer takes 
to decipher messages [KOCH96, KALI96b]. Timing attacks are applicable not just to 
RSA, but to other public-key cryptography systems. This attack is alarming for two 
reasons: It comes from a completely unexpected direction, and it is a ciphertext-only 
attack. 

A timing attack is somewhat analogous to a burglar guessing the combination 
of a safe by observing how long it takes for someone to turn the dial from number to 
number. We can explain the attack using the modular exponentiation algorithm of 
Figure 9.8, but the attack can be adapted to work with any implementation that does 
not run in fixed time. In this algorithm, modular exponentiation is accomplished bit 
by bit, with one modular multiplication performed at each iteration and an addi- 
tional modular multiplication performed for each 1 bit. 

As Kocher points out in his paper, the attack is simplest to understand in an 
extreme case. Suppose the target system uses a modular multiplication function that is 
very fast in almost all cases but in a few cases takes much more time than an entire 
average modular exponentiation. The attack proceeds bit-by-bit starting with the 
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Figure 9.9 MIPS-years Needed to Factor 


leftmost bit, b,. Suppose that the first j bits are known (to obtain the entire exponent, 
start with j = 0 and repeat the attack until the entire exponent is known). For a given 
ciphertext, the attacker can complete the first j iterations of the for loop. The operation 
of the subsequent step depends on the unknown exponent bit. If the bit is set, d <— (d x a) 
mod n will be executed. For a few values of a and d, the modular multiplication will be 
extremely slow, and the attacker knows which these are. Therefore, if the observed time 
to execute the decryption algorithm is always slow when this particular iteration is slow 
with a 1 bit, then this bit is assumed to be 1. If a number of observed execution times for 
the entire algorithm are fast, then this bit is assumed to be 0. 

In practice, modular exponentiation implementations do not have such 
extreme timing variations, in which the execution time of a single iteration can 
exceed the mean execution time of the entire algorithm. Nevertheless, there is 
enough variation to make this attack practical. For details, see [KOCH96]. 


9.2 /THERSA ALGORITHM 289 


Although the timing attack is a serious threat, there are simple countermea- 
sures that can be used, including the following. 


e Constant exponentiation time: Ensure that all exponentiations take the same 
amount of time before returning a result. This is a simple fix but does degrade 
performance. 


e Random delay: Better performance could be achieved by adding a random 
delay to the exponentiation algorithm to confuse the timing attack. Kocher 
points out that if defenders don’t add enough noise, attackers could still succeed 
by collecting additional measurements to compensate for the random delays. 


Blinding: Multiply the ciphertext by a random number before performing 
exponentiation. This process prevents the attacker from knowing what cipher- 
text bits are being processed inside the computer and therefore prevents the 
bit-by-bit analysis essential to the timing attack. 


RSA Data Security incorporates a blinding feature into some of its products. 
The private-key operation M = C4 mod n is implemented as follows. 
1. Generate a secret random number r between 0 and n — 1. 
. Compute C’ = C(r*) mod n, where e is the public exponent. 
. Compute M' =(C’)“ mod n with the ordinary RSA implementation. 


hw NY 


. Compute M= M'r! mod n. In this equation, 7! is the multiplicative inverse of 
rmod n;see Chapter 4 for a discussion of this concept. It can be demonstrated 


that this is the correct result by observing that r°/ mod n = r mod n. 


RSA Data Security reports a 2 to 10% performance penalty for blinding. 


CHOSEN CIPHERTEXT ATTACK AND OPTIMAL ASYMMETRIC ENCRYPTION PADDING The 
basic RSA algorithm is vulnerable to a chosen ciphertext attack (CCA). CCA is 
defined as an attack in which the adversary chooses a number of ciphertexts and is 
then given the corresponding plaintexts, decrypted with the target’s private key. Thus, 
the adversary could select a plaintext, encrypt it with the target’s public key, and then 
be able to get the plaintext back by having it decrypted with the private key. Clearly, 
this provides the adversary with no new information. Instead, the adversary exploits 
properties of RSA and selects blocks of data that, when processed using the target’s 
private key, yield information needed for cryptanalysis. 

A simple example of a CCA against RSA takes advantage of the following 
property of RSA: 


E(PU, M,) x E(PU, M2) = E(PU, [M, x M2]) (9.2) 
We can decrypt C= M° mod n using a CCA as follows. 
1. Compute X= (C x 2°) mod n. 
2. Submit _X as a chosen ciphertext and receive back Y= X“ mod n. 
But now note that 
X = (Cmodn) X (2’mod n) 
= (M°mod n) X (2° mod n) 
= (2M)°modn 
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Therefore, Y = (2M) mod n. From this, we can deduce M. To overcome this 
simple attack, practical RSA-based cryptosystems randomly pad the plaintext prior 
to encryption. This randomizes the ciphertext so that Equation (9.2) no longer 
holds. However, more sophisticated CCAs are possible, and a simple padding with a 
random value has been shown to be insufficient to provide the desired security. To 
counter such attacks, RSA Security Inc., a leading RSA vendor and former holder 
of the RSA patent, recommends modifying the plaintext using a procedure known 
as optimal asymmetric encryption padding (OAEP). A full discussion of the threats 
and OAEP are beyond our scope; see [POIN02] for an introduction and [BELL94a] 
for a thorough analysis. Here, we simply summarize the OAEP procedure. 

Figure 9.10 depicts OAEP encryption. As a first step, the message M to be 
encrypted is padded. A set of optional parameters, P, is passed through a hash function, 
H.° The output is then padded with zeros to get the desired length in the overall data 
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M = message to be encoded MGF = mask generating function 
H = hash function EM = encoded message 


Figure 9.10 Encryption Using Optimal Assymetric 
Encryption Padding (OAEP) 


8A hash function maps a variable-length data block or message into a fixed-length value called a hash 
code. Hash functions are discussed in depth in Chapter 11. 
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block (DB). Next, a random seed is generated and passed through another hash func- 
tion, called the mask generating function (MGF). The resulting hash value is bit-by-bit 
XORed with DB to produce a maskedDB. The maskedDB is in turn passed through 
the MGF to form a hash that is XORed with the seed to produce the masked seed. The 
concatenation of the maskedseed and the maskedDB forms the encoded message EM. 
Note that the EM includes the padded message, masked by the seed, and the seed, 
masked by the maskedDB. The EM is then encrypted using RSA. 


9.3 RECOMMENDED READING AND WEB SITE 


The recommended treatments of encryption listed in Chapter 3 cover public-key as well as 
symmetric encryption. 
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RSA. A more recent discussion is [SHAMO03]. 
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9.4 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


chosen ciphertext attack (CCA) | private key RSA 

digital signature public key time complexity 

key exchange public-key cryptography timing attack 

one-way function public-key cryptosystems trap-door one-way function 

optimal asymmetric encryption | public-key encryption 
padding (OAEP) 
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Review Questions 


9.1 What are the principal elements of a public-key cryptosystem? 
9.2 What are the roles of the public and private key? 
9.3 What are three broad categories of applications of public-key cryptosystems? 
9.4 What requirements must a public key cryptosystems fulfill to be a secure algorithm? 
9.5 What is a one-way function? 
9.6 What is a trap-door one-way function? 
9.7 Describe in general terms an efficient procedure for picking a prime number. 
Problems 
9.1 Prior to the discovery of any specific public-key schemes, such as RSA, an existence 
proof was developed whose purpose was to demonstrate that public-key encryption is 
possible in theory. Consider the functions f,(x1) = 21; fo(%2, y2) = Z23 £3(%3, y3) = Z3, 
where all values are integers with 1 < x;, y;, z; < N. Function f, can be represented by a 
vector M1 of length N, in which the Ath entry is the value of f,(k). Similarly, f, and f, 
can be represented by N x N matrices M2 and M3. The intent is to represent the 
encryption/decryption process by table lookups for tables with very large values of N. 
Such tables would be impractically huge but could be constructed in principle. The 
scheme works as follows: Construct M1 with a random permutation of all integers 
between 1 and N; that is, each integer appears exactly once in M1. Construct M2 so 
that each row contains a random permutation of the first N integers. Finally, fill in M3 
to satisfy the following condition: 
f;(f(£,(k), p), k) = p forallk,pwithl=k,p=WN 
To summarize, 
1. M1 takes an input k and produces an output x. 
2. M2 takes inputs x and p giving output z. 
3. M3 takes inputs z and k and produces p. 
The three tables, once constructed, are made public. 
a. It should be clear that it is possible to construct M3 to satisfy the preceding condi- 
tion. As an example, fill in M3 for the following simple case: 
5 5}2}3/4]1 
4 4);2/5)1)3 
M1 = | 2 M2= /1/3/2)4]5 M3 = 
3 3)1/4)2)]5 
iL 2/5}3/4)]1 
Convention: The ith element of M1 corresponds to k = i. The ith row of M2 
corresponds to x = i; the jth column of M2 corresponds to p = j. The ith row of 
M3 corresponds to z =i; the jth column of M3 corresponds to k =j. 
b. Describe the use of this set of tables to perform encryption and decryption 
between two users. 
c. Argue that this is a secure scheme. 
9.2 Perform encryption and decryption using the RSA algorithm, as in Figure 9.5, for the 


following: 

a. p=3;q=11l,e=7;M=5 
b. p=5;q=11,e=3;M=9 
ec p=7;q=11,e=17;M=8 


9.7 


9.8 


9.9 


9.10 


9.11 
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d. p=11;¢=13,e=11;M=7 
e. p=17;q=31,e=7;M=2 
Hint: Decryption is not as hard as you think; use some finesse. 


In a public-key system using RSA, you intercept the ciphertext C = 10 sent to a user 
whose public key is e= 5, = 35. What is the plaintext M? 


In an RSA system, the public key of a given user is e = 31, = 3599. What is the private 
key of this user? Hint: First use trial-and-error to determine p and q; then use the 
extended Euclidean algorithm to find the multiplicative inverse of 31 modulo #(n). 


In using the RSA algorithm, if a small number of repeated encodings give back the 
plaintext, what is the likely cause? 


Suppose we have a set of blocks encoded with the RSA algorithm and we don’t have the 
private key. Assume n = pq, e is the public key. Suppose also someone tells us they know 
one of the plaintext blocks has a common factor with n. Does this help us in any way? 


In the RSA public-key encryption scheme, each user has a public key, e, and a private 
key, d. Suppose Bob leaks his private key. Rather than generating a new modulus, he 
decides to generate a new public and a new private key. Is this safe? 


Suppose Bob uses the RSA cryptosystem with a very large modulus n for which the 
factorization cannot be found in a reasonable amount of time. Suppose Alice sends a 
message to Bob by representing each alphabetic character as an integer between 0 
and 25 (A > 0, ..., Z—> 25) and then encrypting each number separately using RSA 
with large e and large n. Is this method secure? If not, describe the most efficient 
attack against this encryption method. 


Using a spreadsheet (such as Excel) or a calculator, perform the operations described 
below. Document results of all intermediate modular multiplications. Determine a 
number of modular multiplications per each major transformation (such as encryp- 
tion, decryption, primality testing, etc.). 
a. Test all odd numbers in the range from 233 to 241 for primality using the Miller- 
Rabin test with base 2. 
b. Encrypt the message block M=2 using RSA with the following parameters: e = 23 
and n = 233 x 241. 
c. Compute a private key (d, p,q) corresponding to the given above public key (e, 7). 
d. Perform the decryption of the obtained ciphertext 
1. without using the Chinese Remainder Theorem, and 
2. using the Chinese Remainder Theorem. 


Assume that you generate an authenticated and encrypted message by first applying 
the RSA transformation determined by your private key, and then enciphering the 
message using recipient’s public key (note that you do NOT use hash function 
before the first transformation). Will this scheme work correctly [i.e., give the possi- 
bility to reconstruct the original message at the recipient’s side, for all possible 
relations between the sender’s modulus vg and the recipient’s modulus np (Ng > Np, 
Ng < NR, Ns =NR)|? Explain your answer. In case your answer is “no,” how would you 
correct this scheme? 


“TI want to tell you, Holmes,” Dr. Watson’s voice was enthusiastic, “that your recent 
activities in network security have increased my interest in cryptography. And just 
yesterday I found a way to make one-time pad encryption practical.” 

“Oh, really?” Holmes’ face lost its sleepy look. 

“Yes, Holmes. The idea is quite simple. For a given one-way function F, I gener- 
ate a long pseudorandom sequence of elements by applying F to some standard 
sequence of arguments. The cryptanalyst is assumed to know F and the general nature 
of the sequence, which may be as simple as §,S$ + 1,S+2,..., but not secret S. And 
due to the one-way nature of F, no one is able to extract S given F(S + i) for some i, 
thus even if he somehow obtains a certain segment of the sequence, he will not be 
able to determine the rest.” 
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9.12 
9.13 


9.14 


9.15 


“T am afraid, Watson, that your proposal isn’t without flaws and at least it needs 
some additional conditions to be satisfied by F Let’s consider, for instance, the RSA 
encryption function, that is F/M) = M¥ mod N, K is secret. This function is believed to 
be one- “way, but I wouldn’t recommend its use, for example, on the sequence M = 2, 3, 
4,5, 6, 

“But why, Holmes?” Dr. Watson apparently didn’t understand. ee do you 
think that the resulting sequence 2X mod N, 3“ mod N, 4“ mod N, . . . is not appro- 
priate for one-time pad encryption if K is kept secret?” 

“Because it is—at least partially—predictable, dear Watson, even if K is kept 
secret. You have said that the cryptanalyst is assumed to know F and the general nature 
of the sequence. Now let’s assume that he will obtain somehow a short segment of the 
output sequence. In crypto circles this assumption is generally considered to be a viable 
one. And for this output sequence, knowledge of just the first two elements will allow 
him to predict quite a lot of the next elements of the sequence, even if not all of them, 
thus this sequence can’t be considered to be cryptographically strong. And with the 
knowledge of a longer segment he could predict even more of the next elements of the 
sequence. Look, Knowing the general nature of the sequence and its first two elements 
2* mod N and 3“ mod N, you can easily compute its following elements.” 

Show how this can be done. 

Show how RSA can be represented by matrices M1, M2, and M3 of Problem 9.1. 
Consider the following scheme: 
Pick an odd number, E. 
Pick two prime numbers, P and Q, where (P— 1)(Q — 1) —1 is evenly divisible by E. 
Multiply P and Q to get N. 
(P—1)((Q- 1)(E-1)+1 
E 

Is this scheme equivalent to RSA? Show why or why not. 
Consider the following scheme by which B encrypts a message for A. 
1. A chooses two large primes P and Q that are also relatively prime to (P — 1) 

and (Q — 1). 

. A publishes N= PQ as its public key. 
A calculates P’ and Q' such that. PP' =1 (mod Q—1) and QQ’ =1 (mod P— 1). 


2 

3. 

4. Bencrypts message M as C= MN mod N. 

5. A finds M by solving M= eG (mod Q) and M= ca’ (mod P). 


a. Explain how this scheme works. 

b. How does it differ from RSA? 

c. Is there any particular advantage to RSA compared to this scheme? 

d. Show how this scheme can be represented by matrices M1, M2, and M3 of 
Problem 9.1. 


“This is a very interesting case, Watson,” Holmes said. “The young man loves a girl, 
and she loves him too. However, her father is a strange fellow who insists that his 
would-be son-in-law must design a simple and secure protocol for an appropriate 
public-key cryptosystem he could use in his company’s computer network. The young 
man came up with the following protocol for communication between two parties. 
For example, user A wishing to send message M to user B: (messages exchanged are 
in the format sender’s name, text, receiver’s name)” 

1. Asends B the following block: (A, E(PUp, [M, A]), B). 

2. B acknowledges receipt by sending to A the following block: (B, E(PU,, [M, B]), A). 
“You can see that the protocol is really simple. But the girl’s father claims that the 
young man has not satisfied his call for a simple protocol, because the proposal con- 
tains a certain redundancy and can be further simplified to the following:” 

1. Asends B the block: (A, E(PUs5, M), B). 

2. B acknowledges receipt by sending to A the block: (B, E(PU,, M), A). 


YN 


4. Calculate D = 


9.16 


9.17 


9.18 


9.19 


9.20 
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“On the basis of that, the girl’s father refuses to allow his daughter to marry the young 
man, thus making them both unhappy. The young man was just here to ask me for 
help.” 

“Hmm, I don’t see how you can help him.” Watson was visibly unhappy with the 
idea that the sympathetic young man has to lose his love. 

“Well, I think I could help. You know, Watson, redundancy is sometimes good to 
ensure the security of protocol. Thus, the simplification the girl’s father has proposed 
could make the new protocol vulnerable to an attack the original protocol was able to 
resist,” mused Holmes. “Yes, it is so, Watson. Look, all an adversary needs is to be one 
of the users of the network and to be able to intercept messages exchanged between 
A and B. Being a user of the network, he has his own public encryption key and is able 
to send his own messages to A or to B and to receive theirs. With the help of the sim- 
plified protocol, he could then obtain message M user A has previously sent to B 
using the following procedure:” 

Complete the description. 

Use the fast exponentiation algorithm of Figure 9.8 to determine 5°”° mod 1234. Show 
the steps involved in the computation. 

Here is another realization of the fast exponentiation algorithm. Demonstrate that it 
is equivalent to the one in Figure 9.8. 

£<-— 1; T — a; E <— b 

if odd(e) then f <- £XT 

E <— [ E/2 ] 

To TXT 

if E > 0 then goto 2 

6. output f 


Ve we 


The problem illustrates a simple application of the chosen ciphertext attack. Bob inter- 
cepts a ciphertext C intended for Alice and encrypted with Alice’s public key e. Bob 
wants to obtain the original message M = C“ mod n. Bob chooses a random value r less 
than n and computes 
Z=r'modn 
X=ZCmodn 
t=r!modn 
Next, Bob gets Alice to authenticate (sign) X with her private key (as in Figure 9.3), 
thereby decrypting X. Alice returns Y= X“ mod n. Show how Bob can use the infor- 
mation now available to him to determine M. 
Show the OAEP decoding operation used for decryption that corresponds to the 
encoding operation of Figure 9.10. 
Improve on algorithm P1 in Appendix OB. 
a. Develop an algorithm that requires 2m multiplications and + 1 additions. 
Hint =x #2, 
b. Develop an algorithm that requires only 1 + 1 multiplications and n + 1 additions. 
Hint: P(x) = ag + x X q(x), where q(x) is a polynomial of degree (n — 1). 
The remaining problems concern the knapsack public-key algorithm described in 
Appendix J. 
What items are in the knapsack in Figure F.1? 
Perform encryption and decryption using the knapsack algorithm for the following: 
a. a’=(1,3,5, 10); w=7;m = 20; x= 1101 
b. a’ =(1,3,5,11, 23, 46, 136, 263); w = 203; m = 491; x = 11101000 
c. a’ = (2,3, 6,12, 25); w = 46; m= 53; x= 11101 
d. a’ = (15, 92, 108, 279, 563, 1172, 2243, 4468); w = 2393; m = 9291; x = 10110001 


Why is it a requirement that m > S\a';? 
i=1 


Ill 


Il 
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APPENDIX 9A PROOF OF THE RSA ALGORITHM 


The basic elements of the RSA algorithm can be summarized as follows. Given two 
prime numbers p and q, with n = pq and a message block M < n, two integers e and 
d are chosen such that 


M4 mod n=M 
We state in Section 9.2 that the preceding relationship holds if e and d are multi- 
plicative inverses modulo ¢(n), where (n) is the Euler totient function. It is shown 


in Chapter 8 that for p, g prime, 6(pq) = (p — 1)(q — 1). The relationship between e 
and d can be expressed as 


ed mod ¢(n) =1 
Another way to state this is that there is an integer k such that ed = k(n) + 1. Thus, 
we must show that 


Mke@)+1 modn = M*ke-DG-D+*! mod n=M (9.3) 


Basic Results 
Before proving Equation (9.3), we summarize some basic results. In Chapter 4, we 
showed that a property of modular arithmetic is 

[(a mod n) x (b mod n)] mod n = (a x b) mod n 
From this, it should be easy to see that if we have x mod n = 1, then x?modn=1 and, 
for any integer y, we have x” mod n = 1. Similarly, if we have x mod n = 0 for any 
integer y, we have x” mod n=0. 

Another property of modular arithmetic is 
[(a mod n) — (b mod n)] mod n = (a— b) modn 


The other result we need is Euler’s theorem, which was developed in Chapter 
8. If integers a and n are relatively prime, then a?) mod n= 1. 


Proof 


First we show that M*?~ )(@—)*! mod p = M mod p. There are two cases to consider. 
Case 1: M and p are not relatively prime; that is, p divides M. In this case, M 
mod p =0 and therefore MK? ~ Y@~)*! mod p=0. Thus, MK? ~ DG~ D+! mod 
p=Mmodp. 

Case 2: If M and p are relatively prime, by Euler’s theorem, M*”) mod p = 1. 
We proceed as 
M*’e-DG@-)*1 mod p = (mM) Mre-D@-D1 mod p 

= [(M)(Me~Y)K-)} mod p 

[MyM] mod p 

= (M mod p) X [(M®®) mod p]k@-) 

= (Mmod p) x (1)*4@~)) (by Euler’s theorem) 

= M mod p 
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We now observe that 
[Mee-DG-D+1 _ M4] mod p = [MFP-)G-)*1 mod p] — [M mod p] = 0 


Thus, p divides ee. — M]. By the same reasoning, we can show that 
q divides [M*?-)(G-*! _ ]. Because p and q are distinct primes, there must exist 
an integer r that satisfies 


[MPD — Mf] = (pg)r=nr 


Therefore, n divides [M*?~)(G-)+1 _ Wy], and so Mk9™+! mod n= M*P-VG11 
mod n= M. 
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The central issue in assessing the resistance of an encryption algorithm to crypt- 
analysis is the amount of time that a given type of attack will take. Typically, one can- 
not be sure that one has found the most efficient attack algorithm. The most that 
one can say is that, for a particular algorithm, the level of effort for an attack is of a 
particular order of magnitude. One can then compare that order of magnitude to 
the speed of current or predicted processors to determine the level of security of a 
particular algorithm. 

A common measure of the efficiency of an algorithm is its time complexity. 
We define the time complexity of an algorithm to be f() if, for all n and all 
inputs of length n, the execution of the algorithm takes at most f(”) steps. Thus, 
for a given size of input and a given processor speed, the time complexity is an 
upper bound on the execution time. 

There are several ambiguities here. First, the definition of a step is not pre- 
cise. A step could be a single operation of a Turing machine, a single processor 
machine instruction, a single high-level language machine instruction, and so on. 
However, these various definitions of step should all be related by simple multi- 
plicative constants. For very large values of n, these constants are not important. 
What is important is how fast the relative execution time is growing. For example, 
if we are concerned about whether to use 50-digit (n = 10°’) or 100-digit (n = 
10!) keys for RSA, it is not necessary (or really possible) to know exactly how 
long it would take to break each size of key. Rather, we are interested in ballpark 
figures for level of effort and in knowing how much extra relative effort is 
required for the larger key size. 

A second issue is that, generally speaking, we cannot pin down an exact for- 
mula for f(7). We can only approximate it. But again, we are primarily interested in 
the rate of change of f{() as n becomes very large. 

There is a standard mathematical notation, known as the “big-O” notation, for 
characterizing the time complexity of algorithms that is useful in this context. The 
definition is as follows: f(m) = O(g(n)) if and only if there exist two numbers a and M 
such that 


|f(n)| = a X |g(n)|, n=M (9.4) 
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An example helps clarify the use of this notation. Suppose we wish to evaluate a 
general polynomial of the form 
P(x) = a,x" + ay yx™ +o) + ax + a 
The following simple-minded algorithm is from [POHL81]. 
algorithm Pl; 


n, i, j: integer; x, polyval: real; 
a, S: array [0..100] of real; 


begin 
read(x, n); 
for i := 0 upto n do 
begin 
S[i] := 1; read(a[il]); 
for j := 1 upto i do S[i] := x x S[{il; 
S{i] := afi] x S[il] 
end; 
polyval := 0; 
for i := 0 upto n do polyval := polyval + S[il; 
write (‘value at’, x, ‘is’, polyval) 
end. 


In this algorithm, each subexpression is evaluated separately. Each S[i] 
requires (i + 1) multiplications: i multiplications to compute S[i] and one to multiply 
by a[i]. Computing all n terms requires 


ne (n + 2)(n + 1) 
Zee ly 5 


multiplications. There are also (n + 1) additions, which we can ignore relative to the 
much larger number of multiplications. Thus, the time complexity of this algorithm is 
f(n) =(n + 2)(n + 1)/2. We now show that f(7) = O(n’). From the definition of Equation 
(9.4), we want to show that for a=1 and M = 4 the relationship holds for g(n) = n’. 
We do this by induction on n. The relationship holds for n = 4 because (4 + 2) 
(4 + 1)/2 =15 < 4 = 16. Now assume that it holds for all values of n up to k [i.e., 
(k + 2)(k +1)/2 < k?]. Then, with n=k +1, 


(n+2)(n+1)  (k+3)(k +2) 


d - 2 
k+2k+1 
ae. x ee a, 


P+k+2 
<h+2k+1=(k+1P =n 


IA 


Therefore, the result is true forn=k+ 1. 
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In general, the big-O notation makes use of the term that grows the fastest. 
For example, 


1. Ofax’ + 3x? + sin(x)] = O(ax’) = O(x’) 
. O(e” + an’) = O(e”) 
. O(n! +n) = O(n!) 
There is much more to the big-O notation, with fascinating ramifications. 
For the interested reader, two of the best accounts are in [GRAH94] and 


[KNUT97]. 
An algorithm with an input of size 7 is said to be 


Ww dN 


e Linear: If the running time is O(”) 
¢ Polynomial: If the running time is O(n’) for some constant t 


¢ Exponential: If the running time is O(¢"”) for some constant ¢ and polyno- 
mial h(7) 


Generally, a problem that can be solved in polynomial time is considered fea- 
sible, whereas anything worse than polynomial time, especially exponential time, is 
considered infeasible. But you must be careful with these terms. First, if the size of 
the input is small enough, even very complex algorithms become feasible. Suppose, 
for example, that you have a system that can execute 1012 operations per unit time. 
Table 9.6 shows the size of input that can be handled in one time unit for algorithms 
of various complexities. For algorithms of exponential or factorial time, only very 
small inputs can be accommodated. 

The second thing to be careful about is the way in which the input is 
characterized. For example, the complexity of cryptanalysis of an encryption 
algorithm can be characterized equally well in terms of the number of possible 
keys or the length of the key. For the Advanced Encryption Standard (AES), 
for example, the number of possible keys is 2!78, and the length of the key is 128 
bits. If we consider a single encryption to be a “step” and the number of possible 
keys to be N = 2”, then the time complexity of the algorithm is linear in terms 
of the number of keys [O(NV)] but exponential in terms of the length of the 
key [O(2”)]. 


Table 9.6 Level of Effort for Various Levels of Complexity 


Complexity Size Operations 


logon gio? — 493x10"! 10/2 


10/2 10/2 
10° 10!2 
102 10!2 
39 10!2 
15 02 
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Amongst the tribes of Central Australia every man, woman, and child has a secret 
or sacred name which is bestowed by the older men upon him or her soon after 
birth, and which is known to none but the fully initiated members of the group. 
This secret name is never mentioned except upon the most solemn occasions; to 
utter it in the hearing of men of another group would be a most serious breach of 
tribal custom. When mentioned at all, the name is spoken only in a whisper, and 
not until the most elaborate precautions have been taken that it shall be heard by 
no one but members of the group. The native thinks that a stranger knowing his 
secret name would have special power to work him ill by means of magic. 


—The Golden Bough, Sir James George Frazer 


KEY POINTS 


® A simple public-key algorithm is Diffie-Hellman key exchange. This pro- 
tocol enables two users to establish a secret key using a public-key 
scheme based on discrete logarithms. The protocol is secure only if the 
authenticity of the two participants can be established. 


® Elliptic curve arithmetic can be used to develop a variety of elliptic curve 
cryptography (ECC) schemes, including key exchange, encryption, and 
digital signature. 


© For purposes of ECC, elliptic curve arithmetic involves the use of an elliptic 
curve equation defined over a finite field. The coefficients and variables in 
the equation are elements of a finite field. Schemes using Z, and GF(2”) 
have been developed. 


This chapter begins with a description of one of the earliest and simplest PKCS: Diffie- 
Hellman key exchange. The chapter then looks at another important scheme, the 
ElGamal PKCS. Next, we look at the increasingly important PKCS known as elliptic 
curve cryptography. Finally, the use of public-key algorithms for pseudorandom num- 
ber generation is examined. 


10.1 DIFFIE-HELLMAN KEY EXCHANGE 


The first published public-key algorithm appeared in the seminal paper by Diffie 
and Hellman that defined public-key cryptography [DIFF76b] and is generally 
referred to as Diffie-Hellman key exchange.” A number of commercial products 
employ this key exchange technique. 


'Williamson of Britain’s CESG published the identical scheme a few months earlier in a classified docu- 
ment [WILL76] and claims to have discovered it several years prior to that; see [ELLI99] for a discussion. 
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The purpose of the algorithm is to enable two users to securely exchange a key 
that can then be used for subsequent encryption of messages. The algorithm itself is 
limited to the exchange of secret values. 

The Diffie-Hellman algorithm depends for its effectiveness on the difficulty of 
computing discrete logarithms. Briefly, we can define the discrete logarithm in the 
following way. Recall from Chapter 8 that a primitive root of a prime number p as 
one whose powers modulo p generate all the integers from 1 to p — 1. That is, if ais 
a primitive root of the prime number p, then the numbers 


amod p, a’ mod p, ..., a?~! mod p 


are distinct and consist of the integers from 1 through p — 1 in some permutation. 
For any integer b and a primitive root a of prime number p, we can find a 
unique exponent i such that 


b = a'(mod p) where 0 Si S (p — 1) 


The exponent / is referred to as the discrete logarithm of b for the base a, mod p. We 
express this value as dlog, ,(b). See Chapter 8 for an extended discussion of discrete 
logarithms. 


The Algorithm 


Figure 10.1 summarizes the Diffie-Hellman key exchange algorithm. For this 
scheme, there are two publicly known numbers: a prime number g and an integer a 
that is a primitive root of g. Suppose the users A and B wish to exchange a key. User 
A selects a random integer ¥, < q and computes Y, = a*4modq. Similarly, user 
B independently selects a random integer XY, < q and computes Yz = a**modq. 
Each side keeps the X value private and makes the Y value available publicly to the 
other side. User A computes the key as K = (Y,)**modq and user B computes the 
key as K = (Y4)** mod q . These two calculations produce identical results: 


K = (Y,)*4modq 
= (a** modq)*4mod q 


(a**)*4 mod q by the rules of modular arithmetic 

= a***4mod q 

= (a“4)** modq 

= (a*4modq)** modq 

= (Y4)**modq 

The result is that the two sides have exchanged a secret value. Furthermore, 

because X,, and X, are private, an adversary only has the following ingredients to 
work with: g,a, Y,,and Y,. Thus, the adversary is forced to take a discrete logarithm 


to determine the key. For example, to determine the private key of user B, an adver- 
sary must compute 


Xp = dlogag(Ys) 


The adversary can then calculate the key K in the same manner as user B calculates it. 
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Global Public Elements 
prime number 


a<q and aa primitive root of q 


User A Key Generation 


Select private X , Xy<4 


Calculate public Y , Ya= a*4 mod q 


User B Key Generation 
Select private Xp XpB<q 


Calculate public Yz Yp = a*8 mod q 


Calculation of Secret Key by User A 
K=(Ypz ea mod q 


Calculation of Secret Key by User B 
IK= (Oa mod q 


Figure 10.1. The Diffie-Hellman Key Exchange Algorithm 


The security of the Diffie-Hellman key exchange lies in the fact that, while it is 
relatively easy to calculate exponentials modulo a prime, it is very difficult to calcu- 
late discrete logarithms. For large primes, the latter task is considered infeasible. 

Here is an example. Key exchange is based on the use of the prime number 
q = 353 and a primitive root of 353, in this case a = 3. A and B select secret keys 
X,4 = 97and Xz = 233, respectively. Each computes its public key: 

A computes Y, = 3’’ mod 353 = 40. 


B computes Yz = 37 mod 353 = 248. 
After they exchange public keys, each can compute the common secret key: 


A computes K = (Yx,)*4mod 353 = 248° mod 353 = 160. 
B computes K = (Y,4)** mod 353 = 407° mod 353 = 160. 


We assume an attacker would have available the following information: 


gq = 353;a = 3; Y4 = 40; Yz = 248 
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In this simple example, it would be possible by brute force to determine the secret 
key 160. In particular, an attacker E can determine the common key by discovering 
a solution to the equation 3“ mod 353 = 40 or the equation 3? mod 353 = 248. The 
brute-force approach is to calculate powers of 3 modulo 353, stopping when the 
result equals either 40 or 248. The desired answer is reached with the exponent 
value of 97, which provides 3”’ mod 353 = 40. 

With larger numbers, the problem becomes impractical. 


Key Exchange Protocols 


Figure 10.2 shows a simple protocol that makes use of the Diffie-Hellman calcula- 
tion. Suppose that user A wishes to set up a connection with user B and use a secret 
key to encrypt messages on that connection. User A can generate a one-time private 
key X,, calculate Y,, and send that to user B. User B responds by generating a pri- 
vate value Xz, calculating Y,, and sending Y; to user A. Both users can now calcu- 
late the key. The necessary public values g and a would need to be known ahead of 
time. Alternatively, user A could pick values for g and a and include those in the 
first message. 

As an example of another use of the Diffie-Hellman algorithm, suppose that a 
group of users (e.g., all users on a LAN) each generate a long-lasting private value 
X; (for user i) and calculate a public value Y;. These public values, together with 
global public values for g and a, are stored in some central directory. At any time, 
user j can access user i’s public value, calculate a secret key, and use that to send an 
encrypted message to user A. If the central directory is trusted, then this form of 
communication provides both confidentiality and a degree of authentication. 
Because only i and j can determine the key, no other user can read the message 
(confidentiality). Recipient i knows that only user j could have created a message 
using this key (authentication). However, the technique does not protect against 
replay attacks. 


User A User B 
Generate 
random X4 < q; 
Calculate 
Uae 2) Generate 
random Xz < q; 
Calculate 


Yz = a*B mod q; 


Y Calculate 
B K = (Y,4)*8 mod q 
Calculate 


K = (Y,)*4 mod q 


Figure 10.2 Diffie-Hellman Key Exchange 
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Man-in-the-Middle Attack 


The 


protocol depicted in Figure 10.2 is insecure against a man-in-the-middle attack. 


Suppose Alice and Bob wish to exchange keys, and Darth is the adversary. The 


atta 


1. 


Nn 


and 


ck proceeds as follows. 

Darth prepares for the attack by generating two random private keys Xp, and 

Xp, and then computing the corresponding public keys Yp, and Ypp. 

. Alice transmits Y, to Bob. 

. Darth intercepts Y, and transmits Yp, to Bob. Darth also calculates 
K2 = (Y4)*"mod q. 

. Bob receives Yp; and calculates K1 = (Yp)*#mod q. 

. Bob transmits Yz to Alice. 

. Darth intercepts Ygz and transmits Yp, to Alice. Darth calculates 
K1 = (Yg)*"'mod q. 

. Alice receives Yp, and calculates K2 = (Yp2)*4mod q. 


At this point, Bob and Alice think that they share a secret key, but instead Bob 
Darth share secret key K1 and Alice and Darth share secret key K2. All future 


communication between Bob and Alice is compromised in the following way. 


1 
2. 
3 


not 


. Alice sends an encrypted message M: E(K2, M). 

. Darth intercepts the encrypted message and decrypts it to recover M. 

. Darth sends Bob E(K1, M) or E(K1, M’) , where M' is any message. In the 
first case, Darth simply wants to eavesdrop on the communication without 


altering it. In the second case, Darth wants to modify the message going 
to Bob. 


The key exchange protocol is vulnerable to such an attack because it does 
authenticate the participants. This vulnerability can be overcome with the use 


of digital signatures and public-key certificates; these topics are explored in 
Chapters 13 and 14. 


10.2 ELGAMAL CRYPTOGRAPHIC SYSTEM 


In 1984, T. Elgamal announced a public-key scheme based on discrete logarithms, 
closely related to the Diffie-Hellman technique [ELGA84, ELGA85]. The 
ElGamal’ cryptosystem is used in some form in a number of standards including the 
digital signature standard (DSS), which is covered in Chapter 13, and the S/MIME 
e-mail standard (Chapter 18). 


2For 


no apparent reason, everyone calls this the ElGamal system although Mr. Elgamal’s last name does 


not have a capital letter G. 
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As with Diffie-Hellman, the global elements of El1Gamal are a prime number 


q and a, which is a primitive root of g. User A generates a private/public key pair as 
follows: 


1. 


hw NY 


Nn 


Generate a random integer X,,such that 1 < X, <q -— 1. 


2. Compute Y4 = a*4mod q. 
3. 


A’s private key is X.4; A’s pubic key is {g, a, Y4}. 


Any user B that has access to A’s public key can encrypt a message as follows: 


. Represent the message as an integer M in the range 0 = M =< q — 1. Longer 


messages are sent as a sequence of blocks, with each block being an integer 
less than q. 


. Choose a random integer k such that] = k =q-— 1. 
. Compute a one-time key K = (Y,4)*mod q. 
. Encrypt M as the pair of integers (C;, Cy) where 


C, = a mod q; C,) = KM mod q 


User A recovers the plaintext as follows: 


. Recover the key by computing K = (C,)*4 mod q. 
. Compute M = (C)K') mod q. 


These steps are summarized in Figure 10.3. It corresponds to Figure 9.1a: Alice 


generates a public/private key pair; Bob encrypts using Alice’s public key; and Alice 
decrypts using her private key. 


Let us demonstrate why the ElGamal scheme works. First, we show how K is 


recovered by the decryption process: 


K = (Y,4)* mod q Kis defined during the encryption process 
K = (a*4mod q)* mod q substitute using Y, = a*4mod q 

K = ak*4mod q by the rules of modular arithmetic 

K = (C,)**mod q substitute using C, = aX mod q 


wo ro = 


nn & 


N 


Next, using K, we recover the plaintext as 
C, = KM mod q 
(C.K ') mod g = KMK 'mod q = Mmodq = M 


We can restate the ElGamal process as follows, using Figure 10.3. 


. Bob generates a random integer k. 
. Bob generates a one-time key K using Alice’s public-key components Y 4, gq, and k. 
. Bob encrypts k using the public-key component q, yielding C,. C; provides suffi- 


cient information for Alice to recover K. 


. Bob encrypts the plaintext message M using K. 
. Alice recovers K from C; using her private key. 


. Alice uses K~! to recover the plaintext message from C). 


Global Public Elements 
prime number 


a<qand oa primitive root of g 


Key Generation by Alice 
Select private X , My SGa 
Calculate Y , Y, =a XA mod qd 
Public key LU) = {6.0% Wa)} 


Private key My 


Encryption by Bob with Alice’s Public Key 
Plaintext: M<q 
Select random integer k k<q 
Calculate K K=(Y,)* mod q 
Calculate C, C; = a* mod q 
Calculate C, C> = KM mod q 
Ciphertext: (CoG) 


Decryption by Alice with Alice’s Private Key 
Ciphertext: (Gre) 
Calculate K K=(C, )*4 mod q 


Plaintext: M= (C,K-}) mod q 


Figure 10.3 The ElGamal Cryptosystem 


Thus, K functions as a one-time key, used to encrypt and decrypt the message. 
For example, let us start with the prime field GF(19); that is, g = 19. It has 
primitive roots {2,3, 10, 13, 14, 15}, as shown in Table 8.3. We choose a = 10. 
Alice generates a key pair as follows: 
1. Alice chooses X,4 = 5. 
2. Then Y, = a*4 mod q = a mod 19 = 3 (see Table 8.3). 
3. Alice’s private key is 5; Alice’s pubic key is {q, a, Y4} = {19, 10, 3}. 
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Suppose Bob wants to send the message with the value M = 17. Then, 


- Bob chooses k = 6. 

. Then K = (Y4)* mod q = 3° mod 19 = 729 mod 19 = 7. 
So 

C, = ak mod q = a° mod 19 = 11 

C> = KMmodgq = 7 X 17 mod 19 = 119 mod 19 = 5 

4. Bob sends the ciphertext (11, 5). 


lo 


For decryption: 
. Alice calculates K = (C,)*4 mod q = 11° mod 19 = 161051 mod 19 = 7. 
. Then K 7! in GF(19) is 77! mod 19 = 11. 
. Finally, M = (C)K~!) mod q = 5 X 11 mod 19 = 55 mod 19 = 17. 


we NR - 


If a message must be broken up into blocks and sent as a sequence of 
encrypted blocks, a unique value of k should be used for each block. If k is used for 
more than one block, knowledge of one block m, of the message enables the user to 
compute other blocks as follows. Let 


C,, = aX mod g; C), = KM,mod q 
Ci2 = a* mod q; C7 = KM, mod q 
Then, 


Cr1 _KM,modq _ M,modq 
Cy. KM,modq M,modq 


If M, is known, then M) is easily computed as 
Mz = (C21) | Cy2M, mod q 


The security of ElGamal is based on the difficulty of computing discrete 
logarithms. To recover A’s private key, an adversary would have to compute 
X,4 = dlog,,(Y,4) . Alternatively, to recover the one-time key K, an adversary 
would have to determine the random number k, and this would require comput- 
ing the discrete logarithm k = dlog,,(C,). [STIN06] points out that these calcu- 
lations are regarded as infeasible if p is at least 300 decimal digits and g — 1 has 
at least one “large” prime factor. 


10.3 ELLIPTIC CURVE ARITHMETIC 


Most of the products and standards that use public-key cryptography for encryp- 
tion and digital signatures use RSA. As we have seen, the key length for secure 
RSA use has increased over recent years, and this has put a heavier processing load 
on applications using RSA. This burden has ramifications, especially for electronic 
commerce sites that conduct large numbers of secure transactions. A competing 
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system challenges RSA: elliptic curve cryptography (ECC). ECC is showing up in 
standardization efforts, including the IEEE P1363 Standard for Public-Key 
Cryptography. 

The principal attraction of ECC, compared to RSA, is that it appears to offer 
equal security for a far smaller key size, thereby reducing processing overhead. On 
the other hand, although the theory of ECC has been around for some time, it is 
only recently that products have begun to appear and that there has been sustained 
cryptanalytic interest in probing for weaknesses. Accordingly, the confidence level 
in ECC is not yet as high as that in RSA. 

ECC is fundamentally more difficult to explain than either RSA or Diffie- 
Hellman, and a full mathematical description is beyond the scope of this book. 
This section and the next give some background on elliptic curves and ECC. We 
begin with a brief review of the concept of abelian group. Next, we examine the 
concept of elliptic curves defined over the real numbers. This is followed by a look 
at elliptic curves defined over finite fields. Finally, we are able to examine elliptic 
curve ciphers. 

The reader may wish to review the material on finite fields in Chapter 4 before 
proceeding. 


Abelian Groups 


Recall from Chapter 4 that an abelian group G, sometimes denoted by {G,°*}, is a 
set of elements with a binary operation, denoted by °, that associates to each 
ordered pair (a, b) of elements in G an element (a* b) in G, such that the following 
axioms are obeyed: 


(A1) Closure: If a and b belong to G, then a*b is also in G. 

(A2) Associative: a*(bec) = (aeb)¢c for all a,b,cin G. 

(A3) Identity element: There is an element e in G such that ase = e*a = a for 
all ain G. 


(A4) Inverse element: For each a in G there is an element a’ in G such that 
aca’ =a'ea=e. 


(A5) Commutative: ae b = bea for all a,binG. 


A number of public-key ciphers are based on the use of an abelian group. For 
example, Diffie-Hellman key exchange involves multiplying pairs of nonzero inte- 
gers modulo a prime number q. Keys are generated by exponentiation over the 
group, with exponentiation defined as repeated multiplication. For example, 
a‘ mod q = (a X a X ... X a)mod q. To attack Diffie-Hellman, the attacker must 

_—_ —__ 


k times 
determine k given a and a‘; this is the discrete logarithm problem. 


3The operator ° is generic and can refer to addition, multiplication, or some other mathematical 
operation. 
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For elliptic curve cryptography, an operation over elliptic curves, called addi- 
tion, is used. Multiplication is defined by repeated addition. For example, 


axXk=(a+at... +a) 
ee Y 
k times 


where the addition is performed over an elliptic curve. Cryptanalysis involves deter- 
mining k given a and (a X k). 

An elliptic curve is defined by an equation in two variables with coefficients. For 
cryptography, the variables and coefficients are restricted to elements in a finite field, 
which results in the definition of a finite abelian group. Before looking at this, we first 
look at elliptic curves in which the variables and coefficients are real numbers. This 
case is perhaps easier to visualize. 


Elliptic Curves over Real Numbers 


Elliptic curves are not ellipses. They are so named because they are described by 
cubic equations, similar to those used for calculating the circumference of an ellipse. 
In general, cubic equations for elliptic curves take the following form, known as a 
Weierstrass equation: 


y+ axy + by=x+cx*+ dx +e 


where a, b, c, d, e are real numbers and x and y take on values in the real numbers.* 
For our purpose, it is sufficient to limit ourselves to equations of the form 


yp=axrtaxthb (10.1) 


Such equations are said to be cubic, or of degree 3, because the highest expo- 
nent they contain is a 3. Also included in the definition of an elliptic curve is a single 
element denoted O and called the point at infinity or the zero point, which we 
discuss subsequently. To plot such a curve, we need to compute 


y=Vxe+ax+b 


For given values of a and 5, the plot consists of positive and negative values of y for 
each value of x. Thus, each curve is symmetric about y = 0. Figure 10.4 shows two 
examples of elliptic curves. As you can see, the formula sometimes produces weird- 
looking curves. 

Now, consider the set of points E(a, b) consisting of all of the points (x, y) that 
satisfy Equation (10.1) together with the element O. Using a different value of the 
pair (a, b) results in a different set E(a, b). Using this terminology, the two curves in 
Figure 10.4 depict the sets E(—1, 0) and E(1, 1), respectively. 


GEOMETRIC DESCRIPTION OF ADDITION It can be shown that a group can be defined 
based on the set E(a, b) for specific values of a and b in Equation (10.1), provided 
the following condition is met: 


4a> + 27b? # 0 (10.2) 


4Note that x and y are true variables, which take on values. This is in contrast to our discussion of poly- 
nomial rings and fields in Chapter 4, where x was treated as an indeterminate. 
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(b) =x +xt+ 1 
Figure 10.4 Example of Elliptic Curves 


To define the group, we must define an operation, called addition and denoted by +, 
for the set E(a, b), where a and b satisfy Equation (10.2). In geometric terms, the 
rules for addition can be stated as follows: If three points on an elliptic curve lie on 
a straight line, their sum is O. From this definition, we can define the rules of addi- 
tion over an elliptic curve. 


1. O serves as the additive identity. Thus O = —O; for any point P on the elliptic 
curve, P + O = P.In what follows, we assume P # O and QO # O. 

2. The negative of a point P is the point with the same x coordinate but the negative 
of the y coordinate; that is, if P = (x, y), then —P = (x, —y). Note that these two 
points can be joined by a vertical line. Note that P + (-P) = P—- P= 0. 
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3. To add two points P and Q with different x coordinates, draw a straight line 
between them and find the third point of intersection R. It is easily seen that 
there is a unique point R that is the point of intersection (unless the line is tan- 
gent to the curve at either P or Q, in which case we take R = P or R= Q, 
respectively). To form a group structure, we need to define addition on these 
three points: P + Q = —R. That is, we define P + Q to be the mirror image 
(with respect to the x axis) of the third point of intersection. Figure 10.4 illustrates 
this construction. 


4. The geometric interpretation of the preceding item also applies to two points, P 
and —P, with the same x coordinate. The points are joined by a vertical line, 
which can be viewed as also intersecting the curve at the infinity point. We there- 
fore have P + (—P) = O, which is consistent with item (2). 


. To double a point Q, draw the tangent line and find the other point of inter- 
section S. Then QO + QO = 20 = -S. 


mn 


With the preceding list of rules, it can be shown that the set E(a, b) is an 
abelian group. 


ALGEBRAIC DESCRIPTION OF ADDITION In this subsection, we present some results 
that enable calculation of additions over elliptic curves.” For two distinct points, 
P = (xp, yp) and Q = (xg, yg), that are not negatives of each other, the slope of the 
line / that joins them is A = (yg — yp)/(Xg — Xp) . There is exactly one other point 
where / intersects the elliptic curve, and that is the negative of the sum of P and Q. 
After some algebraic manipulation, we can express the sum R = P + Qas 


Xp = A? = tp = tp 
Yr = —yp + A(xp — xp) 


We also need to be able to add a point to itself: P + P = 2P = R. When 
yp # 0, the expressions are 


(10.3) 


(10.4) 


Elliptic Curves over Z, 


Elliptic curve cryptography makes use of elliptic curves in which the variables and 
coefficients are all restricted to elements of a finite field. Two families of elliptic 
curves are used in cryptographic applications: prime curves over Z, and binary 
curves over GF(2”). For a prime curve over Z,,, we use a cubic equation in which the 
variables and coefficients all take on values in the set of integers from 0 through 
p — (and in which calculations are performed modulo p. For a binary curve defined 


>For derivations of these results, see [KOBL94] or other mathematical treatments of elliptic curves. 
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over GF(2”), the variables and coefficients all take on values in GF(2”) and in cal- 
culations are performed over GF(2”). [FERN99] points out that prime curves are 
best for software applications, because the extended bit-fiddling operations needed 
by binary curves are not required; and that binary curves are best for hardware 
applications, where it takes remarkably few logic gates to create a powerful, fast 
cryptosystem. We examine these two families in this section and the next. 

There is no obvious geometric interpretation of elliptic curve arithmetic over 
finite fields. The algebraic interpretation used for elliptic curve arithmetic over real 
numbers does readily carry over, and this is the approach we take. 

For elliptic curves over Z,, as with real numbers, we limit ourselves to equa- 
tions of the form of Equation (10.1), but in this case with coefficients and variables 
limited to Z,: 


y’modp = (x° + ax + b) modp (10.5) 


For example, Equation (10.5) is satisfied fora = 1,b=1,x=9,y=7,a=1 
p = 23: 
7 mod 23 = (9° + 9 + 1) mod 23 
49 mod 23 = 739 mod 23 
3=3 

Now consider the set E,(a, b) consisting of all pairs of integers (x, y) that sat- 
isfy Equation (10.5), together with a point at infinity O.The coefficients a and b and 
the variables x and y are all elements of Z,,. 

For example, let p = 23 and consider the elliptic curve y? = x° + x + 1.In 
this case, a = b = 1. Note that this equation is the same as that of Figure 10.4b. 
The figure shows a continuous curve with all of the real points that satisfy the 
equation. For the set E,3(1, 1), we are only interested in the nonnegative integers 
in the quadrant from (0, 0) through (p — 1, p — 1) that satisfy the equation mod 
p. Table 10.1 lists the points (other than O) that are part of E>3(1, 1). Figure 10.5 
plots the points of E,3(1, 1); note that the points, with one exception, are symmetric 
about y = 11.5. 


Table 10.1 Points on the Elliptic Curve E53 (1,1) 
(6, 4) (12, 19) 
(6,19) (157) 
(7,11) (13, 16) 
(7,12) (17,3) 
(9,7) (17,20) 


(9, 16) (18, 3) 
(11,3) (18, 20) 
(11, 20) (19, 5) 
(12,4) (19, 18) 
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‘e 10.5 The Elliptic Curve E,3(1, 1) 


It can be shown that a finite abelian group can be defined based on the set 
E,(a, b) provided that (x? + ax + b) modp has no repeated factors. This is equiva- 
lent to the condition 


(4a3 + 27b”) modp # 0 modp (10.6) 


Note that Equation (10.6) has the same form as Equation (10.2). 
The rules for addition over E,(a, b), correspond to the algebraic technique 
described for elliptic curves defined over real numbers. For all points P, Q € E,(a, b): 


lL. P+O=P. 

2. If P = (xp, yp) , then P + (xp,—yp) = O. The point (xp,—yp) is the negative 
of P, denoted as —P. For example, in F,3(1,1), for P = (13,7), we have 
—P = (13, —7). But —7 mod 23 = 16. Therefore, —P = (13,16), which is also 
in E53(1, 1). 

If P = (xp,yp) and Q = (xg, yg) with P # —Q, then R = P + Q = (xp, yr) is 
determined by the following rules: 


Xp = (A* — xp — xg) mod p 


Yr = (A(xp — Xp) — yp) mod p 
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where 

Yo yp . 
——— }modp ifP#Q 
XQ — Xp 

A= 

3xp +a 

( ) moa p ifP=Q 
2yp 


4. Multiplication is defined as repeated addition; for example, 4P = 
P+ P+ P+ P, 


For example, let P = (3, 10) and Q = (9, 7) in Ey3(1, 1). Then 


7-10 -3 -1 
A= ( 9-3 ) mod 23 = (2) moas = (<1) moa23 = 11 
Xp = (11° — 3 — 9)mod 23 = 109 mod 23 = 17 


yr = (11(3 — 17) — 10)mod 23 = —164 mod 23 = 20 
So P + Q = (17, 20).To find 2P, 


a= C=") a2 = (3) a3 = (4) d23=6 
“Ie. Se ae 


The last step in the preceding equation involves taking the multiplicative 
inverse of 4in Z53. This can be done using the extended Euclidean algorithm defined 
in Section 4.4. To confirm, note that (6 < 4) mod 23 = 24 mod 23 = 1. 

Xp = (6 — 3 — 3) mod 23 = 30 mod 23 = 7 
yr = (633 — 7) — 10) mod 23 = (—34) mod 23 = 12 
and 2P = (7, 12). 
For determining the security of various elliptic curve ciphers, it is of some inter- 


est to know the number of points in a finite abelian group defined over an elliptic 
curve. In the case of the finite group Ep(a, b), the number of points N is bounded by 


pti-®Vp2]N=p41+4+2Vp 


Note that the number of points in E,,(a, b) is approximately equal to the number of 
elements in Z,, namely p elements. 


Elliptic Curves over GF(2") 


Recall from Chapter 4 that a finite field GF(2”) consists of 2” elements, together 
with addition and multiplication operations that can be defined over polynomials. 
For elliptic curves over GF(2”"), we use a cubic equation in which the variables and 
coefficients all take on values in GF(2”) for some number m and in which calcula- 
tions are performed using the rules of arithmetic in GF(2”). 

It turns out that the form of cubic equation appropriate for cryptographic appli- 
cations for elliptic curves is somewhat different for GF(2”) than for Z,. The form is 


ytxeu=xrtaxrt+b (10.7) 
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Table 10.2 Points on the Elliptic Curve E>:(g*, 1) 
(Ge) 
(g'". 8) 
Ge 
(g'”, 0) 


(g°, g°) 
(g°, g'!) 


(g°, g°) 
(s°, g'*) 
(g’, g'°) Gg 2) 


where it is understood that the variables x and y and the coefficients a and b are 
elements of GF(2”) and that calculations are performed in GF(2”). 

Now consider the set E>»(a, b) consisting of all pairs of integers (x, y) that 
satisfy Equation (10.7), together with a point at infinity O. 

For example, let us use the finite field GF(2*) with the irreducible polynomial 
f(x) = x4 + x + 1. This yields a generator g that satisfies f(g) = 0 with a value of 
g* = g + 1, or in binary, g = 0010. We can develop the powers of g as follows. 


g? = 0001 g' = 0011 g® = 0101 g? = 1111 
g' = 0010 g> = 0110 g? = 1010 eg? = 1101 
g = 0100 g® = 1100 gl = 0111 gi* = 1001 
@ = 1000 g’ = 1011 g'! = 1110 g = 0001 


For example, g° = (g*)(g) = g° + g = 0110. 
Now consider the elliptic curve y? + xy = x° + gtx? + 1. In this case, a = g4 
and b = g° = 1. One point that satisfies this equation is (g°, g°): 


SY + #8) = &Y + BEY +1 

oo + go = gl + git 4] 

1100 + 0101 = 0001 + 1001 + 0001 

1001 = 1001 
Table 10.2 lists the points (other than O) that are part of E>:(g*, 1). Figure 10.6 plots 
the points of E>:(g*, 1). 

It can be shown that a finite abelian group can be defined based on the set 
E;»(a, b), provided that b # 0.The rules for addition can be stated as follows. For all 
points P,Q © E>»(a, b): 

1P+O=P. 


2. If P= (xp, yp) 5 then P + (xp, Xp + yp) = O. The point (xp, Xp - yp) is the 
negative of P, which is denoted as —P. 


3. If P=(xp,yp) and Q=(xg,yg) with P#-Q and P#Q, then 
R= P+ Q = (xp, yr) is determined by the following rules: 


Xp=M+A+xptxgta 
Yr = A(xp + xr) + XR + yp 
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Figure 10.6 The Elliptic Curve E, (g*, 1) 
where 


yo + yp 
Xo + Xp 


4. If P = (xp, yp) then R = 2P = (xp, yr) is determined by the following rules: 
Xp=M+A+a 


YR Xp + (A + 1x)p 


where 
yp 


A=xXxpt — 
Xp 


10.4 ELLIPTIC CURVE CRYPTOGRAPHY 


The addition operation in ECC is the counterpart of modular multiplication in 
RSA, and multiple addition is the counterpart of modular exponentiation. To form a 
cryptographic system using elliptic curves, we need to find a “hard problem” corre- 
sponding to factoring the product of two primes or taking the discrete logarithm. 

Consider the equation Q = kP where QO, P € Ep(a, b) and k < p. It is rela- 
tively easy to calculate Q given k and P, but it is relatively hard to determine k given 
Q and P. This is called the discrete logarithm problem for elliptic curves. 

We give an example taken from the Certicom Web site (www.certicom.com). 
Consider the group E,3(9,17). This is the group defined by the equation 
y* mod 23 = (x* + 9x + 17) mod 23. What is the discrete logarithm k of Q = (4, 5) 
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to the base P = (16,5)? The brute-force method is to compute multiples of P until 
QO is found. Thus, 


P = (16,5); 2P = (20, 20); 3P = (14, 14); 4P = (19, 20); 5P = (13, 10); 
6P = (7,3); 7P = (8,7); 8P = (12,17); 9P = (4,5) 


Because 9P = (4,5) = Q, the discrete logarithm Q = (4,5) to the base 
P = (16,5) is k = 9. Ina real application, k would be so large as to make the brute- 
force approach infeasible. 

In the remainder of this section, we show two approaches to ECC that give the 
flavor of this technique. 


Analog of Diffie-Hellman Key Exchange 


Key exchange using elliptic curves can be done in the following manner. First pick a 
large integer q, which is either a prime number p or an integer of the form 2”, and 
elliptic curve parameters a and b for Equation (10.5) or Equation (10.7). This 
defines the elliptic group of points E,(a, b). Next, pick a base point G = (x, y;) in 
E,(a, b) whose order is a very large value n. The order n of a point G on an elliptic 
curve is the smallest positive integer n such that nG = 0 and G are parameters of 
the cryptosystem known to all participants. 

A key exchange between users A and B can be accomplished as follows 
(Figure 10.7). 


1. A selects an integer n, less than n. This is A’s private key. A then generates a 
public key P4 = n4 X G; the public key is a point in E,(a, b). 


2. B similarly selects a private key ng and computes a public key Pz. 


io) 


. A generates the secret key k =n, X Pz. B generates the secret key 
k= nB x PAs 


The two calculations in step 3 produce the same result because 
ny X Pp = ng X (ng X G) = ng X (ng X G) = ng X Pa 


To break this scheme, an attacker would need to be able to compute k given G 
and kG, which is assumed to be hard. 

As an example,° take p = 211; E,(0, —4), which is equivalent to the curve 
y? =x — 4;andG = (2,2). One can calculate that 240G = O.A’s private key is 
na = 121, so A’s public key is P, = 121(2,2) = (115,48). B’s private key 
is nB = 203, so B’s public key is 203(2, 3) = (130, 203). The shared secret key is 
121(130, 203) = 203(115, 48) = (161, 69). 

Note that the secret key is a pair of numbers. If this key is to be used as 
a session key for conventional encryption, then a single number must be gener- 
ated. We could simply use the x coordinates or some simple function of the x 
coordinate. 


Provided by Ed Schaefer of Santa Clara University. 
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Global Public Elements 


elliptic curve with parameters a, b, and q, where q is a 
prime or an integer of the form 2’” 


point on elliptic curve whose order is large value n 


User A Key Generation 
Select private n, nyg<n 


Calculate public P, P,=n,xG 


User B Key Generation 


Select private ng Ng <n 


Calculate public Pp Pp=NngxXG 


Calculation of Secret Key by User A 


Calculation of Secret Key by User B 


Figure 10.7 ECC Diffie-Hellman Key Exchange 


Elliptic Curve Encryption/Decryption 


Several approaches to encryption/decryption using elliptic curves have been ana- 
lyzed in the literature. In this subsection, we look at perhaps the simplest. The first 
task in this system is to encode the plaintext message m to be sent as an x-y point 
P.,. It is the point P,, that will be encrypted as a ciphertext and subsequently 
decrypted. Note that we cannot simply encode the message as the x or y coordinate 
of a point, because not all such coordinates are in E,(a, b); for example, see Table 
10.1. Again, there are several approaches to this encoding, which we will not 
address here, but suffice it to say that there are relatively straightforward tech- 
niques that can be used. 

As with the key exchange system, an encryption/decryption system requires a 
point G and an elliptic group E,(a, b) as parameters. Each user A selects a private 
key ny, and generates a public key Py = ny X G. 
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To encrypt and send a message P,,, to B, A chooses a random positive integer k 
and produces the ciphertext C,, consisting of the pair of points: 


Cn = {kG, P,, + kP3} 


Note that A has used B’s public key Pg. To decrypt the ciphertext, B multiplies the 
first point in the pair by B’s secret key and subtracts the result from the second 
point: 


P,, + kPp —_ np(kG) = Py + k(ngG) _ np(kG) = Py 


A has masked the message P,,, by adding kPz to it. Nobody but A knows the 
value of k, so even though P, is a public key, nobody can remove the mask kPz. 
However, A also includes a “clue,” which is enough to remove the mask if one 
knows the private key ng. For an attacker to recover the message, the attacker 
would have to compute k given G and kG, which is assumed to be hard. 

As an example of the encryption process (taken from [KOBL94]), take 
p = 751; E,(-1, 188), which is equivalent to the curve y’ = x° — x + 188; and 
G = (0,376). Suppose that A wishes to send a message to B that is encoded in the 
elliptic point P,,, = (562, 201) and that A selects the random number k = 386. B’s 
public key is Pg = (291,5). We have 386(0, 376) = (676,558), and (562, 201) + 
386(201, 5) = (385, 328). Thus, A sends the cipher text {(676, 558), (385, 328)}. 


Security of Elliptic Curve Cryptography 


The security of ECC depends on how difficult it is to determine k given kP and P. 
This is referred to as the elliptic curve logarithm problem. The fastest known tech- 
nique for taking the elliptic curve logarithm is known as the Pollard rho method. 
Table 10.3 compares various algorithms by showing comparable key sizes in terms 
of computational effort for cryptanalysis. As can be seen, a considerably smaller key 
size can be used for ECC compared to RSA. Furthermore, for equal key lengths, the 
computational effort required for ECC and RSA is comparable [JURI97]. Thus, 
there is a computational advantage to using ECC with a shorter key length than a 
comparably secure RSA. 


Table 10.3 Comparable Key Sizes in Terms of Computational Effort for Cryptanalysis 


Symmetric Scheme ECC-Based Scheme RSA/DSA 
(key size in bits) (size of n in bits) (modulus size in bits) 

56 ily 512 

80 160 1024 
112 224 2048 
128 256 3072 
192 384 7680 
256 Sil 15360 


Source: Certicom 
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10.5 PSEUDORANDOM NUMBER GENERATION BASED 
ON AN ASYMMETRIC CIPHER 


We noted in Chapter 7 that because a symmetric block cipher produces an appar- 
ently random output, it can serve as the basis of a pseudorandom number generator 
(PRNG). Similarly, an asymmetric encryption algorithm produces apparently 
random output and can be used to build a PRNG. Because asymmetric algorithms 
are typically much slower than symmetric algorithms, asymmetric algorithms are 
not used to generate open-ended PRNG bit streams. Rather, the asymmetric 
approach is useful for creating a pseudorandom function (PRF) for generating a 
short pseudorandom bit sequence. 

In this section, we examine two PRNG designs based on pseudorandom 
functions. 


PRNG Based on RSA 


For a sufficient key length, the RSA algorithm is considered secure and is a good 
candidate to form the basis of a PRNG. Such a PRNG, known as the Micali-Schnorr 
PRNG [MICA91], is recommended in the ANSI standard X9.82 (Random Number 
Generation) and in the ISO standard 18031 (Random Bit Generation). 

The PRNG is illustrated in Figure 10.8. As can be seen, this PRNG has much the 
same structure as the output feedback (OFB) mode used as a PRNG (see Figure 7.3b 
and the portion of Figure 6.6a enclosed with a dashed box). In this case, the encryp- 
tion algorithm is RSA rather than a symmetric block cipher. Also, a portion of the 
output is fed back to the next iteration of the encryption algorithm and the remain- 
der of the output is used as pseudorandom bits. The motivation for this separation of 
the output into two distinct parts is so that the pseudorandom bits from one stage do 
not provide input to the next stage. This separation should contribute to forward 
unpredictability. 


Encrypt 
yy =Xp mod n 


x, =r most 
significant bits 


x2 =r most 
significant bits 


x3 =r most 
significant bits 


zy =k least Z2 =k least 73 =k least 
significant bits significant bits significant bits 


Figure 10.8 Micali-Schnorr Pseudorandom Bit Generator 
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We can define the PRNG as follows. 


Setup Select p,q primes; n = pq;d(n) = (p — 1)(q — 1). Select e such that 
gcd(e, f(n)) = 1.These are the standard RSA setup selections (see 
Figure 9.5). In addition, let N = |log,n| + 1 (the bitlength of 7). Select 
r,k such thatr + k = N. 


Seed Select a random seed Xo of bitlength r. 


Generate Generate a pseudorandom sequence of length k X m using the loop 
for i from 1 to m do 
y; = xf_,;modn 
x; = r most significant bits of y; 
z, = k least significant bits of y; 


Output The output sequence is Z Il zz Il... Il Z,). 


The parameters n, r, e, and k are selected to satisfy the following six 


requirements. 

1. n = pq n is chosen as the product of two primes to have 
the cryptographic strength required of RSA. 

2.1 <e< (n); gcd (e,é(n)) = 1 Ensures that the mapping s > s* modn 
is 1 to 1. 

3. re = 2N Ensures that the exponentiation requires a full 
modular reduction. 

4. r = 2 strength Protects against a cryptographic attacks. 

5. k,r are multiples of 8 An implementation convenience. 

6k2=8:r+k=N All bits are used. 


The variable strength in requirement 4 is defined in NIST SP 800-90 as follows: 
A number associated with the amount of work (that is, the number of operations) 
required to break a cryptographic algorithm or system; a security strength is speci- 
fied in bits and is a specific value from the set (112, 128, 192, 256) for this 
Recommendation. The amount of work needed is 2°", 

There is clearly a tradeoff between r and k. Because RSA is computation- 
ally intensive compared to a block cipher, we would like to generate as many 
pseudorandom bits per iteration as possible and therefore would like a large 
value of k. However, for cryptographic strength, we would like r to be as large as 
possible. 

For example, if e = 3 and N = 1024, then we have the inequality 3r > 1024, 
yielding a minimum required size for r of 683 bits. For r set to that size,k = 341 bits 
are generated for each exponentiation (each RSA encryption). In this case, each 
exponentiation requires only one modular squaring of a 683-bit number and one 
modular multiplication. That is, we need only calculate (x; X (x? mod n))modn. 
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PRNG Based on Elliptic Curve Cryptography 


In this subsection, we briefly summarize a technique developed by the U.S. National 
Security Agency (NSA) known as dual elliptic curve PRNG (DEC PRNG). This 
technique is recommended in NIST SP 800-90, the ANSI standard X9.82, and the 
ISO standard 18031. There has been some controversy regarding both the security 
and efficiency of this algorithm compared to other alternatives (e.g., see [SCHO06], 
[BROW07]). 

[SCHO06] summarizes the algorithm as follows: Let P and Q be two known 
points on a given elliptic curve. The seed of the DEC PRNG is a random integer 
so © {0, 1, ..., AE(GF(p)) — 1}, where # E(GF(p)) denotes the number of points 
on the curve. Let x denote a function that gives the x-coordinate of a point of the curve. 
Let /sb,(s) denote the i least significant bits of an integer s. The DEC PRNG trans- 
forms the seed into the pseudorandom sequence of length 240k, k > 0, as follows. 


for i= 1 to k do 
Set Ss; 
Set rj; 

end for 


— x(Sj-, P) 
<— lsb240 (x (Ss; Q) ) 
REEUEN. Fy pao. 4 hg 


Given the security concerns expressed for this PRNG, the only motivation for 
its use would be that it is used in a system that already implements ECC but does 
not implement any other symmetric, asymmetric, or hash cryptographic algorithm 
that could be used to build a PRNG. 


10.6 RECOMMENDED READING AND WEB SITE 


A quite readable treatment of elliptic curve cryptography is [ROSI99]; the emphasis is on 
software implementation. Another readable, but rigorous, book is [HANK04]. Two other 
good treatments, both of which contain some rather stiff mathematics, are [BLAK99] and 
[ENGE99]. There are also good but more concise descriptions in [KUMA98], [STIN06], and 
[KOBL94]. Two interesting survey treatments are [FERN99] and [JURI97]. 


BLAK99 Blake, I.; Seroussi, G.; and Smart, N. Elliptic Curves in Cryptography. 
Cambridge: Cambridge University Press, 1999. 

ENGE99 Enge, A. Elliptic Curves and Their Applications to Cryptography. Norwell, MA: 
Kluwer Academic Publishers, 1999. 

FERN99 Fernandes, A. “Elliptic Curve Cryptography.” Dr. Dobb’s Journal, December 


IG9Q), 

HANKO04 Hankerson, D.; Menezes, A.; and Vanstone, S. Guide to Elliptic Curve 
Cryptography. New York: Springer, 2004. 

JURI97 Jurisic, A., and Menezes, A. “Elliptic Curves and Cryptography.” Dr. Dobb’s 
Journal, April 1997. 
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KOBL94 Koblitz, N. A Course in Number Theory and Cryptography. New York: Springer- 
Verlag, 1994. 

KUMA98 Kumanduri, R., and Romero, C. Number Theory with Computer Applications. 
Upper Saddle River, NJ: Prentice Hall, 1998. 


ROSI99 Rosing, M. Implementing Elliptic Curve Cryptography. Greeenwich, CT: 
Manning Publications, 1999. 
STIN06 Stinson, D. Cryptography: Theory and Practice. Boca Raton, FL: CRC Press, 2006. 


Recommended Web Site: 


e Certicom: Extensive collection of technical material on elliptic curve cryptography and 
other topics in cryptography. 


10.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


abelian group elliptic curve Micali-Schnorr 
binary curve elliptic curve arithmetic prime curve 


cubic equation elliptic curve cryptography primitive root 
Diffie-Hellman key exchange | finite field zero point 


discrete logarithm man-the-middle attack 


Review Questions 


10.1 Briefly explain Diffie-Hellman key exchange. 

10.2 What is an elliptic curve? 

10.3 What is the zero point of an elliptic curve? 

10.4 What is the sum of three points on an elliptic curve that lie on a straight line? 


Problems 


10.1 Users A and B use the Diffie-Hellman key exchange technique with a common prime 
q = 71 and a primitive root a = 7. 
a. Ifuser A has private key X, = 5, what is A’s public key Y,? 
b. Ifuser B has private key Xz = 12, what is B’s public key Y,? 
c. What is the shared secret key? 
10.2 Consider a Diffie-Hellman scheme with a common prime g = 11 and a primitive root 
a=2. 
a. Show that 2 is a primitive root of 11. 
b. Ifuser A has public key Y, = 9, what is A’s private key X 4? 
c. Ifuser B has public key Ygz = 3, what is the secret key K shared with A? 


10.3 


10.4 


10.5 


10.6 


10.7 


10.8 


10.9 
10.10 


10.11 


10.12 


10.13 


10.14 


10.15 
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In the Diffie-Hellman protocol, each participant selects a secret number x and sends 
the other participant a* mod q for some public number a. What would happen if the 
participants sent each other x* for some public number a instead? Give at least one 
method Alice and Bob could use to agree on a key. Can Eve break your system with- 
out finding the secret numbers? Can Eve find the secret numbers? 

This problem illustrates the point that the Diffie-Hellman protocol is not secure with- 
out the step where you take the modulus; i.e. the “Indiscrete Log Problem” is not a 
hard problem! You are Eve and have captured Alice and Bob and imprisoned them. 
You overhear the following dialog. 


Bob: Oh, let’s not bother with the prime in the Diffie-Hellman protocol, it will 
make things easier. 


Alice: Okay, but we still need a base © to raise things to. How about g = 3? 
Bob: All right, then my result is 27. 
Alice: And mine is 243. 


What is Bob’s secret X, and Alice’s secret X,? What is their secret combined key? 

(Don’t forget to show your work.) 

Section 10.2 describes a man-in-the-middle attack on the Diffie-Hellman key 

exchange protocol in which the adversary generates two public-private key pairs for 

the attack. Could the same attack be accomplished with one pair? Explain. 

Consider an ElGamal scheme with a common prime g = 71 and a primitive root 

a=7. 

a. If B has public key Yz = 3 and A chose the random integer k = 2, what is the 
ciphertext of M = 30? 

b. If A now chooses a different value of k so that the encoding of M = 30 is 
C = (59, Cy), what is the integer C,? 

Rule (5) for doing arithmetic in elliptic curves over real numbers states that to double 

a point Q>, draw the tangent line and find the other point of intersection S. Then 

Q + Q=2Q = —S If the tangent line is not vertical, there will be exactly one point 

of intersection. However, suppose the tangent line is vertical? In that case, what is the 

value 2Q? What is the value 3Q? 

Demonstrate that the two elliptic curves of Figure 10.4 each satisfy the conditions for 

a group over the real numbers. 


Is (4,7) a point on the elliptic curve y> = x* — 5x + 5 over real numbers? 


On the elliptic curve over the real numbers y? = x* — 36x, let P = (—3.5, 9.5) and 

Q = (—2.5, 8.5). Find P + Q and 2P. 

Does the elliptic curve equation y? = x*7 + 10x + 5 define a group over Z,7? 

Consider the elliptic curve Ej,(1, 6); that is, the curve is defined by y* = x° + x + 6 

with a modulus of p = 11. Determine all of the points in E;,(1, 6). Hint: Start by cal- 

culating the right-hand side of the equation for all values of x. 

What are the negatives of the following elliptic curve points over Z,7? P = (5, 8); Q = 

(3, 0); R = (0,6). 

For E;,(1, 6), consider the point G = (2,7). Compute the multiples of G from 2G 

through 13G. 

This problem performs elliptic curve encryption/decryption using the scheme out- 

lined in Section 10.4. The cryptosystem parameters are E,,(1, 6) and G = (2,7). B’s 

secret key is ng = 7. 

a. Find B’s public key Pz. 

b. A wishes to encrypt the message P,,, = (10,9) and chooses the random value 
k = 3. Determine the ciphertext C,,,. 

c. Show the calculation by which B recovers P,,, from Cy. 
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10.16 


10.17 


The following is a first attempt at an elliptic curve signature scheme. We have a global 

elliptic curve, prime p, and “generator” G. Alice picks a private signing key X, and 

forms the public verifying key Y, = X,G.To sign a message M: 

e Alice picks a value k. 

e Alice sends Bob M,k and the signature S = M — kX ,G. 

e Bob verifies that M = S$ + kY4. 

a. Show that this scheme works. That is, show that the verification process produces 
an equality if the signature is valid. 

b. Show that the scheme is unacceptable by describing a simple technique for forg- 
ing a user’s signature on an arbitrary message. 

Here is an improved version of the scheme given in the previous problem. As before, 

we have a global elliptic curve, prime p, and “generator” G. Alice picks a private sign- 

ing key X, and forms the public verifying key Y, = X,G.To sign a message M: 

e Bob picks a value k. 

e Bob sends Alice C, = kG. 

e Alice sends Bob M and the signature S = M — X,4Cj. 

e Bob verifies that M = S$ + kY,. 

a. Show that this scheme works. That is, show that the verification process produces 
an equality if the signature is valid. 

b. Show that forging a message in this scheme is as hard as breaking (ElGamal) 
elliptic curve cryptography. (Or find an easier way to forge a message?) 

c. This scheme has an extra “pass” compared to other cryptosystems and signature 
schemes we have looked at. What are some drawbacks to this? 
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Each of the messages, like each one he had ever read of Stern’s commands, began 
with a number and ended with a number or row of numbers. No efforts on the part 
of Mungo or any of his experts had been able to break Stern’s code, nor was there 
any Clue as to what the preliminary number and those ultimate numbers signified. 


—Talking to Strange Men, Ruth Rendell 


The Douglas Squirrel has a distinctive eating habit. It usually eats pine cones 
from the bottom end up. Partially eaten cones can indicate the presence of these 
squirrels if they have been attacked from the bottom first. If, instead, the cone has 
been eaten from the top end down, it is more likely to have been a crossbill finch 
that has been doing the dining. 


—Squirrels: A Wildlife Handbook, Kim Long 


KEY POINTS 


® A hash function maps a variable-length message into a fixed-length hash 
value, or message digest. 


® Virtually all cryptographic hash functions involve the iterative use of a 
compression function. 


® The compression function used in secure hash algorithms falls into one of 
two categories: a function specifically designed for the hash function or an 
algorithm based on a symmetric block cipher. SHA and Whirlpool are 
examples of these two approaches, respectively. 


A hash function H accepts a variable-length block of data M as input and produces 
a fixed-size hash value h = H(M).A “good” hash function has the property that the 
results of applying the function to a large set of inputs will produce outputs that are 
evenly distributed and apparently random. In general terms, the principal object of 
a hash function is data integrity. A change to any bit or bits in M results, with high 
probability, in a change to the hash code. 

The kind of hash function needed for security applications is referred to as a 
cryptographic hash function. A cryptographic hash function is an algorithm for which 
it is computationally infeasible (because no attack is significantly more efficient than 
brute force) to find either (a) a data object that maps to a pre-specified hash result 
(the one-way property) or (b) two data objects that map to the same hash result 
(the collision-free property). Because of these characteristics, hash functions are often 
used to determine whether or not data has changed. 

Figure 11.1 depicts the general operation of a cryptographic hash function. 
Typically, the input is padded out to an integer multiple of some fixed length (e.g., 1024 
bits), and the padding includes the value of the length of the original message in bits. The 
length field is a security measure to increase the difficulty for an attacker to produce an 
alternative message with the same hash value. 
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L bits 


—— 
Message or data block M (variable length) 


Hash value h 
(fixed length) 


Figure 11.1 Black Diagram of Cryptographic 
Hash Function; h = H(M) 


This chapter begins with a discussion of the wide variety of applications for 
cryptographic hash functions. Next, we look at the security requirements for such 
functions. Then we look at the use of cipher block chaining to implement a crypto- 
graphic hash function. The remainder of the chapter is devoted to the most impor- 
tant and widely used family of cryptographic hash functions, the Secure Hash 
Algorithm (SHA) family. 

Appendix N describes Whirlpool, another popular cryptographic hash function. 


11.1 APPLICATIONS OF CRYPTOGRAPHIC HASH FUNCTIONS 


Perhaps the most versatile cryptographic algorithm is the cryptographic hash function. 
It is used in a wide variety of security applications and Internet protocols. To better 
understand some of the requirements and security implications for cryptographic hash 
functions, it is useful to look at the range of applications in which it is employed. 


Message Authentication 


Message authentication is a mechanism or service used to verify the integrity of a 
message. Message authentication assures that data received are exactly as sent 
(i.e., contain no modification, insertion, deletion, or replay). In many cases, there is 
a requirement that the authentication mechanism assures that purported identity 
of the sender is valid. When a hash function is used to provide message authenti- 
cation, the hash function value is often referred to as a message digest. 

Figure 11.2 illustrates a variety of ways in which a hash code can be used to 
provide message authentication, as follows. 
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Figure 11.2 Simplified Examples of the Use of a Hash Function for Message Authentication 


a. The message plus concatenated hash code is encrypted using symmetric 
encryption. Because only A and B share the secret key, the message must have 
come from A and has not been altered. The hash code provides the structure 
or redundancy required to achieve authentication. Because encryption is 
applied to the entire message plus hash code, confidentiality is also provided. 


b. Only the hash code is encrypted, using symmetric encryption. This reduces the 
processing burden for those applications that do not require confidentiality. 


c. It is possible to use a hash function but no encryption for message authentication. 
The technique assumes that the two communicating parties share a common 
secret value S.A computes the hash value over the concatenation of M and S and 
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appends the resulting hash value to M. Because B possesses S, it can recompute 
the hash value to verify. Because the secret value itself is not sent, an opponent 
cannot modify an intercepted message and cannot generate a false message. 


d. Confidentiality can be added to the approach of method (c) by encrypting the 
entire message plus the hash code. 


When confidentiality is not required, method (b) has an advantage over methods 
(a) and (d), which encrypts the entire message, in that less computation is required. 
Nevertheless, there has been growing interest in techniques that avoid encryption 
(Figure 11.2c). Several reasons for this interest are pointed out in [TSUD92]. 


e Encryption software is relatively slow. Even though the amount of data to be 
encrypted per message is small, there may be a steady stream of messages into 
and out of a system. 


e Encryption hardware costs are not negligible. Low-cost chip implementations 
of DES are available, but the cost adds up if all nodes in a network must have 
this capability. 

e Encryption hardware is optimized toward large data sizes. For small blocks of 
data, a high proportion of the time is spent in initialization/invocation overhead. 


e Encryption algorithms may be covered by patents, and there is a cost associated 
with licensing their use. 


More commonly, message authentication is achieved using a message authentica- 
tion code (MAC), also known as a keyed hash function. Typically, MACs are used 
between two parties that share a secret key to authenticate information exchanged 
between those parties. A MAC function takes as input a secret key and a data block 
and produces a hash value, referred to as the MAC. This can then be transmitted with 
or stored with the protected message. If the integrity of the message needs to be 
checked, the MAC function can be applied to the message and the result compared 
with the stored MAC value. An attacker who alters the message will be unable to alter 
the MAC value without knowledge of the secret key. Note that the verifying party also 
knows who the sending party is because no one else knows the secret key. 

Note that the combination of hashing and encryption results in an overall 
function that is, in fact,a MAC (Figure 11.2b). That is, E(K, H(M)) is a function of a 
variable-length message M and a secret key K, and it produces a fixed-size output 
that is secure against an opponent who does not know the secret key. In practice, 
specific MAC algorithms are designed that are generally more efficient than an 
encryption algorithm. 

We discuss MACs in Chapter 12. 


Digital Signatures 


Another important application, which is similar to the message authentication 
application, is the digital signature. The operation of the digital signature is similar 
to that of the MAC. In the case of the digital signature, the hash value of a message 
is encrypted with a user’s private key. Anyone who knows the user’s public key can 
verify the integrity of the message that is associated with the digital signature. In this 
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case, an attacker who wishes to alter the message would need to know the user’s 
private key. As we shall see in Chapter 14, the implications of digital signatures go 
beyond just message authentication. 

Figure 11.3 illustrates, in a simplified fashion, how a hash code is used to 
provide a digital signature. 


a. The hash code is encrypted, using public-key encryption with the sender’s pri- 
vate key. As with Figure 11.2b, this provides authentication. It also provides a 
digital signature, because only the sender could have produced the encrypted 
hash code. In fact, this is the essence of the digital signature technique. 


b. If confidentiality as well as a digital signature is desired, then the message plus 
the private-key-encrypted hash code can be encrypted using a symmetric 
secret key. This is a common technique. 


Other Applications 


Hash functions are commonly used to create a one-way password file. Chapter 20 
explains a scheme in which a hash of a password is stored by an operating system 
rather than the password itself. Thus, the actual password is not retrievable by a hacker 
who gains access to the password file. In simple terms, when a user enters a password, 
the hash of that password is compared to the stored hash value for verification. This 
approach to password protection is used by most operating systems. 

Hash functions can be used for intrusion detection and virus detection. Store 
H(F) for each file on a system and secure the hash values (e.g., on a CD-R that is 


2+ — Source A 2+ —\ Destination B————»> 


Compare 


(a) E(PR,, H(M)) 


E(K, [M || E(PR,, H(M))]) 


E(PR,, Hi 
i (PRq HM) 


Figure 11.3 Simplified Examples of Digital Signatures 
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kept secure). One can later determine if a file has been modified by recomputing 
H(F). An intruder would need to change F without changing H(F). 

A cryptographic hash function can be used to construct a pseudorandom func- 
tion (PRF) or a pseudorandom number generator (PRNG). A common application 
for a hash-based PRF is for the generation of symmetric keys. We discuss this appli- 
cation in Chapter 12. 


11.2 TWO SIMPLE HASH FUNCTIONS 


To get some feel for the security considerations involved in cryptographic hash 
functions, we present two simple, insecure hash functions in this section. All hash 
functions operate using the following general principles. The input (message, file, 
etc.) is viewed as a sequence of n-bit blocks. The input is processed one block at a 
time in an iterative fashion to produce an n-bit hash function. 

One of the simplest hash functions is the bit-by-bit exclusive-OR (XOR) of 
every block. This can be expressed as 


Ci = bn @ ba © abe ® Dim 


where 
C; = ith bit of the hash code,1 =i=n 
m = number of n-bit blocks in the input 
bj = ith bit in jth block 


@ = XOR operation 


This operation produces a simple parity for each bit position and is known as 
a longitudinal redundancy check. It is reasonably effective for random data as a 
data integrity check. Each n-bit hash value is equally likely. Thus, the probability 
that a data error will result in an unchanged hash value is 2”. With more 
predictably formatted data, the function is less effective. For example, in most 
normal text files, the high-order bit of each octet is always zero. So if a 128-bit 
hash value is used, instead of an effectiveness of 2~!*°, the hash function on this 
type of data has an effectiveness of 27!'”. 

A simple way to improve matters is to perform a one-bit circular shift, or rota- 
tion, on the hash value after each block is processed. The procedure can be summa- 
rized as follows. 


1. Initially set the n-bit hash value to zero. 
2. Process each successive n-bit block of data as follows: 
a. Rotate the current hash value to the left by one bit. 
b. XOR the block into the hash value. 
This has the effect of “randomizing” the input more completely and overcoming any 
regularities that appear in the input. Figure 11.4 illustrates these two types of hash 
functions for 16-bit hash values. 


Although the second procedure provides a good measure of data integrity, it is 
virtually useless for data security when an encrypted hash code is used with a plaintext 
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Figure 11.4 Two Simple Hash Functions 


message, as in Figures 11.2b and 11.3a. Given a message, it is an easy matter to 
produce a new message that yields that hash code: Simply prepare the desired 
alternate message and then append an n-bit block that forces the new message plus 
block to yield the desired hash code. 

Although a simple XOR or rotated XOR (RXOR) is insufficient if only the 
hash code is encrypted, you may still feel that such a simple function could be 
useful when the message together with the hash code is encrypted (Figure 11.2a). 
But you must be careful. A technique originally proposed by the National Bureau 
of Standards used the simple XOR applied to 64-bit blocks of the message and 
then an encryption of the entire message that used the cipher block chaining 
(CBC) mode. We can define the scheme as follows: Given a message M consisting 
of a sequence of 64-bit blocks X,, X>,..., Xy, define the hash code h = H(M) as 
the block-by-block XOR of all blocks and append the hash code as the final 
block: 


h= Xyu = X%1042@0-.-OXn 
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Next, encrypt the entire message plus hash code using CBC mode to produce the 
encrypted message Yj, Yo, ..., Yn. [JUEN85] points out several ways in which the 
ciphertext of this message can be manipulated in such a way that it is not detectable 
by the hash code. For example, by the definition of CBC (Figure 6.4), we have 


X, =1IV@ DK, Y;) 
X; = Yi-1 © DKK, Yj) 
Xwut = Yy © DKK, Yy1) 
But Xj, 1s the hash code: 


Xn = X18 X2@ ara ® Xn 
=VO@ODK, Y)1 O11 O DK, ¥2)] @ --- © Yn-1 © DK, Yy))] 


Because the terms in the preceding equation can be XORed in any order, it follows 
that the hash code would not change if the ciphertext blocks were permuted. 


11.3 REQUIREMENTS AND SECURITY 


Before proceeding, we need to define two terms. For a hash value h = H(x), we say 
that x is the preimage of h. That is, x is a data block whose hash function, using the 
function H, is h. Because H is a many-to-one mapping, for any given hash value h, 
there will in general be multiple preimages. A collision occurs if we have x # y and 
H(x) = H(y). Because we are using hash functions for data integrity, collisions are 
clearly undesirable. 

Let us consider how many preimages are there for a given hash value, which is 
a measure of the number of potential collisions for a given hash value. Suppose the 
length of the hash code is n bits, and the function H takes as input messages or data 
blocks of length b bits with b > n. Then, the total number of possible messages is 2? 
and the total number of possible hash values is 2”. On average, each hash value 
corresponds to 2°” preimages. If H tends to uniformly distribute hash values then, in 
fact, each hash value will have close to 2?” preimages. If we now allow inputs of 
arbitrary length, not just a fixed length of some number of bits, then the number of 
preimages per hash value is arbitrarily large. However, the security risks in the use 
of a hash function are not as severe as they might appear from this analysis. 
To understand better the security implications of cryptographic hash functions, we 
need precisely define their security requirements. 


Security Requirements for Cryptographic Hash Functions 


Table 11.1 lists the generally accepted requirements for a cryptographic hash function. 
The first three properties are requirements for the practical application of a hash 
function. 

The fourth property, preimage resistant, is the one-way property: it is easy to 
generate a code given a message, but virtually impossible to generate a message 
given a code. This property is important if the authentication technique involves the 
use of a secret value (Figure 11.2c). The secret value itself is not sent. However, if the 
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Table 11.1 Requirements for a Cryptographic Hash Function H 


Requirement Description 


Variable input size H can be applied to a block of data of any size. 


Fixed output size H produces a fixed-length output. 


Efficiency H(x) is relatively easy to compute for any given x, 
making both hardware and software implementa- 
tions practical. 


Preimage resistant (one-way property) For any given hash value h, it is computationally 


infeasible to find y such that H(y) = h. 


Second preimage resistant (weak collision For any given block x, it is computationally 
resistant) infeasible to find y 4 x with H(y) = H(x). 


Collision resistant (strong collision resistant) It is computationally infeasible to find any pair 
(x, y) such that H(x) = H(y). 


Pseudorandomness Output of H meets standard tests for 
pseudorandomness. 


hash function is not one way, an attacker can easily discover the secret value: If the 
attacker can observe or intercept a transmission, the attacker obtains the message 
M, and the hash code h = H(S||M).The attacker then inverts the hash function to 
obtain S|| M = H-'(MDy). Because the attacker now has both M and S4,|| M, it is 
a trivial matter to recover S4p. 

The fifth property, second preimage resistant, guarantees that it is impossible to 
find an alternative message with the same hash value as a given message. This pre- 
vents forgery when an encrypted hash code is used (Figure 11.2b and Figure 11.3a). 
If this property were not true, an attacker would be capable of the following 
sequence: First, observe or intercept a message plus its encrypted hash code; second, 
generate an unencrypted hash code from the message; third, generate an alternate 
message with the same hash code. 

A hash function that satisfies the first five properties in Table 11.1 is referred 
to as a weak hash function. If the sixth property, collision resistant, is also satisfied, 
then it is referred to as a strong hash function. A strong hash function protects 
against an attack in which one party generates a message for another party to sign. 
For example, suppose Bob writes an IOU message, sends it to Alice, and she signs 
it. Bob finds two messages with the same hash, one of which requires Alice to pay a 
small amount and one that requires a large payment. Alice signs the first message, 
and Bob is then able to claim that the second message is authentic. 

Figure 11.5 shows the relationships among the three resistant properties. 
A function that is collision resistant is also second preimage resistant, but the 
reverse is not necessarily true. A function can be collision resistant but not preimage 
resistant and vice versa. A function can be collision resistant but not second 
preimage resistant and vice versa. See [MENE97] for a discussion. 

Table 11.2 shows the resistant properties required for various hash function 
applications. 
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Figure 11.5 Relationship Among Hash Function 
Properties 


The final requirement in Table 11.1, pseudorandomness, has not traditionally 
been listed as a requirement of cryptographic hash functions but is more or less 
implied. [JOHNOS] points out that cryptographic hash functions are commonly used 
for key derivation and pseudorandom number generation, and that in message 
integrity applications, the three resistant properties depend on the output of the 
hash function appearing to be random. Thus, it makes sense to verify that in fact a 
given hash function produces pseudorandom output. 


Brute-Force Attacks 


As with encryption algorithms, there are two categories of attacks on hash functions: 
brute-force attacks and cryptanalysis. A brute-force attack does not depend on the 
specific algorithm but depends only on bit length. In the case of a hash function, a 
brute-force attack depends only on the bit length of the hash value. A cryptanalysis, 
in contrast, is an attack based on weaknesses in a particular cryptographic algorithm. 
We look first at brute-force attacks. 


Table 11.2 Hash Function Resistance Properties Required for Various Data Integrity 
Applications 


Preimage Resistant | Second Preimage | Collision Resistant 
Resistant 


Hash + digital signature 


Intrusion detection and virus 
detection 


Hash + symmetric encryption 


One-way password file 


MAC 


* Resistance required if attacker is able to mount a chosen message attack 
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PREIMAGE AND SECOND PREIMAGE ATTACKS For a preimage or second preimage 
attack, an adversary wishes to find a value y such that H(y) is equal to a given hash 
value h. The brute-force method is to pick values of y at random and try each value 
until a collision occurs. For an m-bit hash value, the level of effort is proportional to 
2". Specifically, the adversary would have to try, on average, 2"! values of y to find 
one that generates a given hash value h. This result is derived in Appendix 11A 
[Equation (11.1)]. 


COLLISION RESISTANT ATTACKS For a collision resistant attack, an adversary 
wishes to find two messages or data blocks, x and y, that yield the same hash 
function: H(x) = H(y). This turns out to require considerably less effort than a 
preimage or second preimage attack. The effort required is explained by a 
mathematical result referred to as the birthday paradox. In essence, if we choose 
random variables from a uniform distribution in the range 0 through N — 1, then 
the probability that a repeated element is encountered exceeds 0.5 after VN 
choices have been made. Thus, for an m-bit hash value, if we pick data blocks at 
random, we can expect to find two data blocks with the same hash value within 
Vom = pmi2 attempts. The mathematical derivation of this result is found in 
Appendix 11A. 

Yuval proposed the following strategy to exploit the birthday paradox in a 
collision resistant attack [YUVA79]. 


1. The source, A, is prepared to sign a legitimate message x by appending the 
appropriate m-bit hash code and encrypting that hash code with A’s private 
key (Figure 11.3a). 


. The opponent generates 2”” variations x’ of x, all of which convey essentially the 
same meaning, and stores the messages and their hash values. 


nN 


3. The opponent prepares a fraudulent message y for which A’s signature is desired. 


4. The opponent generates minor variations y’ of y, all of which convey essentially 
the same meaning. For each y’, the opponent computes H(y’), checks for 
matches with any of the H(x’) values, and continues until a match is found. That 
is, the process continues until a y’ is generated with a hash value equal to the hash 
value of one of the x’ values. 


Nn 


The opponent offers the valid variation to A for signature. This signature can 
then be attached to the fraudulent variation for transmission to the intended 
recipient. Because the two variations have the same hash code, they will 
produce the same signature; the opponent is assured of success even though 
the encryption key is not known. 


Thus, if a 64-bit hash code is used, the level of effort required is only on the 
order of 2°” [see Appendix 11A, Equation (11.7)]. 

The generation of many variations that convey the same meaning is not difficult. 
For example, the opponent could insert a number of “space-space-backspace” charac- 
ter pairs between words throughout the document. Variations could then be gener- 
ated by substituting “space-backspace-space” in selected instances. Alternatively, the 
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Figure 11.6 A Letter in 2°” Variation [DAVI89] 


opponent could simply reword the message but retain the meaning. Figure 11.6 
[DAVI89] provides an example. 

To summarize, for a hash code of length m, the level of effort required, as we 
have seen, is proportional to the following. 


Preimage resistant 2 


Second preimage resistant 2 


Collision resistant gine 
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If collision resistance is required (and this is desirable for a general-purpose 
secure hash code), then the value 2’? determines the strength of the hash 
code against brute-force attacks. Van Oorschot and Wiener [VANO94] presented a 
design for a $10 million collision search machine for MDS, which has a 128-bit hash 
length, that could find a collision in 24 days. Thus, a 128-bit code may be viewed as 
inadequate. The next step up, if a hash code is treated as a sequence of 32 bits, is a 
160-bit hash length. With a hash length of 160 bits, the same search machine would 
require over four thousand years to find a collision. With today’s technology, the 
time would be much shorter, so that 160 bits now appears suspect. 


Cryptanalysis 


As with encryption algorithms, cryptanalytic attacks on hash functions seek to 
exploit some property of the algorithm to perform some attack other than an 
exhaustive search. The way to measure the resistance of a hash algorithm to crypt- 
analysis is to compare its strength to the effort required for a brute-force attack. 
That is, an ideal hash algorithm will require a cryptanalytic effort greater than or 
equal to the brute-force effort. 

In recent years, there has been considerable effort, and some successes, in devel- 
oping cryptanalytic attacks on hash functions. To understand these, we need to look at 
the overall structure of a typical secure hash function, indicated in Figure 11.7. This 
structure, referred to as an iterated hash function, was proposed by Merkle [MERK79, 
MERK839] and is the structure of most hash functions in use today, including SHA, 
which is discussed later in this chapter. The hash function takes an input message and 
partitions it into L fixed-sized blocks of b bits each. If necessary, the final block is 
padded to b bits. The final block also includes the value of the total length of the input 
to the hash function. The inclusion of the length makes the job of the opponent more 
difficult. Either the opponent must find two messages of equal length that hash to the 
same value or two messages of differing lengths that, together with their length values, 
hash to the same value. 

The hash algorithm involves repeated use of a compression function, f, that 
takes two inputs (an n-bit input from the previous step, called the chaining variable, 
and a b-bit block) and produces an n-bit output. At the start of hashing, the chaining 
variable has an initial value that is specified as part of the algorithm. The final value 
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Figure 11.7 General Structure of Secure Hash Code 
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of the chaining variable is the hash value. Often, b > n; hence the term 
compression. The hash function can be summarized as 

CV = IV = initial n-bit value 

CV; = f{(CV; » Yj 1) 1sisL 


where the input to the hash function is a message M consisting of the blocks 
Vo; Vig. wacg Y 4s 

The motivation for this iterative structure stems from the observation by Merkle 
[MERK89] and Damgard [DAMG89] that if the compression function is collision resis- 
tant, then so is the resultant iterated hash function. Therefore, the structure can be used 
to produce a secure hash function to operate on a message of any length. The problem 
of designing a secure hash function reduces to that of designing a collision-resistant 
compression function that operates on inputs of some fixed size. 

Cryptanalysis of hash functions focuses on the internal structure of f and is 
based on attempts to find efficient techniques for producing collisions for a single 
execution of f. Once that is done, the attack must take into account the fixed value of 
IV. The attack on f depends on exploiting its internal structure. Typically, as with 
symmetric block ciphers, f consists of a series of rounds of processing, so that the 
attack involves analysis of the pattern of bit changes from round to round. 

Keep in mind that for any hash function there must exist collisions, because we 
are mapping a message of length at least equal to twice the block size b (because we 
must append a length field) into a hash code of length n, where b = n. What is 
required is that it is computationally infeasible to find collisions. 

The attacks that have been mounted on hash functions are rather complex 
and beyond our scope here. For the interested reader, [DOBB96] and [BELL97] 
are recommended. 


11.4 HASH FUNCTIONS BASED ON CIPHER BLOCK CHAINING 


A number of proposals have been made for hash functions based on using a cipher 
block chaining technique, but without using the secret key. One of the first such 
proposals was that of Rabin [RABI78]. Divide a message M into fixed-size blocks 
M,, M>, ..., My and use a symmetric encryption system such as DES to compute 
the hash code G as 


Hy = initial value 
H; = E(M, H;-1) 
G= An 


This is similar to the CBC technique, but in this case, there is no secret key. As with any 
hash code, this scheme is subject to the birthday attack, and if the encryption algorithm 
is DES and only a 64-bit hash code is produced, then the system is vulnerable. 


|The converse is not necessarily true. 
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Furthermore, another version of the birthday attack can be used even if the 
opponent has access to only one message and its valid signature and cannot 
obtain multiple signings. Here is the scenario: We assume that the opponent 
intercepts a message with a signature in the form of an encrypted hash code and 
that the unencrypted hash code is m bits long. 


—_ 


. Use the algorithm defined at the beginning of this subsection to calculate the 
unencrypted hash code G. 


2. Construct any desired message in the form Q;, Qo, ..., Qn->. 
3. Compute H; = E(Q;, H;-1) for 1 = i = (N — 2). 
4. Generate 2” random blocks; for each block X, compute E(X, Hy-2). Generate 


an additional 2””” random blocks; for each block Y, compute D(Y, G), where D is 
the decryption function corresponding to E. 


5. Based on the birthday paradox, with high probability there will be an X and Y 
such that E(X, Hy_2) = D(Y, G). 

6. Form the message Q), Qo, ..., Ov—2, X, Y. This message has the hash code G 
and therefore can be used with the intercepted encrypted signature. 


This form of attack is known as a meet-in-the-middle-attack. A number 
of researchers have proposed refinements intended to strengthen the basic 
block chaining approach. For example, Davies and Price [DAVI89] describe the 
variation: 


H, = EM, Hi) © Ha 
Another variation, proposed in [MEYE88], is 
HA; = E(Hj-1, Mi) © M; 


However, both of these schemes have been shown to be vulnerable to a variety 
of attacks [MIYA90]. More generally, it can be shown that some form of birthday 
attack will succeed against any hash scheme involving the use of cipher block chain- 
ing without a secret key, provided that either the resulting hash code is small enough 
(e.g., 64 bits or less) or that a larger hash code can be decomposed into independent 
subcodes [JUEN87]. 

Thus, attention has been directed at finding other approaches to hashing. 
Many of these have also been shown to have weaknesses [MITC92]. 


11.5 SECURE HASH ALGORITHM (SHA) 


In recent years, the most widely used hash function has been the Secure Hash 
Algorithm (SHA). Indeed, because virtually every other widely used hash func- 
tion had been found to have substantial cryptanalytic weaknesses, SHA was more 
or less the last remaining standardized hash algorithm by 2005. SHA was devel- 
oped by the National Institute of Standards and Technology (NIST) and published 
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as a federal information processing standard (FIPS 180) in 1993. When weak- 
nesses were discovered in SHA, now known as SHA-0, a revised version was 
issued as FIPS 180-1 in 1995 and is referred to as SHA-1. The actual standards 
document is entitled “Secure Hash Standard.” SHA is based on the hash function 
MD4, and its design closely models MD4. SHA-1 is also specified in RFC 
3174, which essentially duplicates the material in FIPS 180-1 but adds a C code 
implementation. 

SHA-1 produces a hash value of 160 bits. In 2002, NIST produced a revised 
version of the standard, FIPS 180-2, that defined three new versions of SHA, with 
hash value lengths of 256, 384, and 512 bits, known as SHA-256, SHA-384, and 
SHA-512, respectively. Collectively, these hash algorithms are known as SHA-2. 
These new versions have the same underlying structure and use the same types of 
modular arithmetic and logical binary operations as SHA-1. A revised document 
was issued as FIP PUB 180-3 in 2008, which added a 224-bit version (Table 11.3). 
SHA-2 is also specified in RFC 4634, which essentially duplicates the material in 
FIPS 180-3 but adds a C code implementation. 

In 2005, NIST announced the intention to phase out approval of SHA-1 and 
move to a reliance on SHA-2 by 2010. Shortly thereafter, a research team described 
an attack in which two separate messages could be found that deliver the same 
SHA-1 hash using 2™ operations, far fewer than the 2°° operations previously 
thought needed to find a collision with an SHA-1 hash [WANGO5]. This result 
should hasten the transition to SHA-2. 

In this section, we provide a description of SHA-512. The other versions are 
quite similar. 


SHA-512 Logic 


The algorithm takes as input a message with a maximum length of less than 2'”* bits 
and produces as output a 512-bit message digest. The input is processed in 1024-bit 
blocks. Figure 11.8 depicts the overall processing of a message to produce a digest. 
This follows the general structure depicted in Figure 11.7. The processing consists of 
the following steps. 


Table 11.3 Comparison of SHA Parameters 


SHA-1 SHA-224 SHA-256 SHA-384 SHA-512 
Message 160 224 256 384 Sil2 
Digest Size 
Message Size < 264 < 264 < 264 < 7128 < 7128 
Block Size Sil Sil2 512 1024 1024 
Word Size 52 32 BZ 64 64 
Number of Steps 80 64 64 80 80 


Note: All sizes are measured in bits. 
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Nx1024 bits > 
128 bits 

L bits > <S 

Message 1000000, . . . ,0} 
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512 bits 512 bits 512 bits 


F 


Step 1 


Step 2 


Step 3 


hash code 


+ =word-by-word addition mod 2 


‘igure 11.8 Message Digest Generation Using SHA-512 


Append padding bits. The message is padded so that its length is congruent 
to 896 modulo 1024 [length = 896(mod 1024)]. Padding is always added, 
even if the message is already of the desired length. Thus, the number of 
padding bits is in the range of 1 to 1024. The padding consists of a single 1 
bit followed by the necessary number of 0 bits. 


Append length. A block of 128 bits is appended to the message. This block is 
treated as an unsigned 128-bit integer (most significant byte first) and contains 
the length of the original message (before the padding). 

The outcome of the first two steps yields a message that is an integer 
multiple of 1024 bits in length. In Figure 11.8, the expanded message is repre- 
sented as the sequence of 1024-bit blocks M,, M>, ..., My, so that the total 
length of the expanded message is N X 1024 bits. 


Initialize hash buffer. A 512-bit buffer is used to hold intermediate and final 
results of the hash function. The buffer can be represented as eight 64-bit reg- 
isters (a, b,c, d, e, f, g, h). These registers are initialized to the following 64-bit 
integers (hexadecimal values): 


a = 6A09E667F3BCC908 e = 510E527FADE682D1 
b = BB67AE8584CAA73B £ = 9B05688C2B3E6C1F 
c = 3C6EF372FE94F82B g = 1F83D9ABFB41BD6B 


Qu 
Il 


A54FF53A5F1D36F1 h = 5BEOCD19137E2179 


Step 4 
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These values are stored in big-endian format, which is the most significant 
byte of a word in the low-address (leftmost) byte position. These words were 
obtained by taking the first sixty-four bits of the fractional parts of the square 
roots of the first eight prime numbers. 


Process message in 1024-bit (128-word) blocks. The heart of the algorithm 
is a module that consists of 80 rounds; this module is labeled F in Figure 11.8. 
The logic is illustrated in Figure 11.9. 

Each round takes as input the 512-bit buffer value, abcdefgh, and updates 
the contents of the buffer. At input to the first round, the buffer has the value of 
the intermediate hash value, H;_,. Each round t makes use of a 64-bit value W,, 
derived from the current 1024-bit block being processed (M;). These values are 
derived using a message schedule described subsequently. Each round also 
makes use of an additive constant K,, where 0 = t = 79 indicates one of the 
80 rounds. These words represent the first 64 bits of the fractional parts of the 
cube roots of the first 80 prime numbers. The constants provide a “randomized” 
set of 64-bit patterns, which should eliminate any regularities in the input data. 
Table 11.4 shows these constants in hexadecimal format (from left to right). 

The output of the eightieth round is added to the input to the first round 
(H;_1) to produce H;. The addition is done independently for each of the eight 


M; Aj-} 
es |; | 
us Round 0 eg 

tim 

° 


, AAd4 dad, 


W79 


4 4 4"4 mal 
( 


Ky 
Round 79 <— 


Figure 11.9 SHA-512 Processing of a Single 1024-Bit Block 
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words in the buffer with each of the corresponding words in H;_,, using addi- 
tion modulo 2%, 


Step 5 Output. After all N 1024-bit blocks have been processed, the output from 
the Nth stage is the 512-bit message digest. 


We can summarize the behavior of SHA-512 as follows: 


Hy) = IV 
A, = SUM ¢4(4Aj-1, abcdefgh,) 
MD = Hy 
where 
IV = initial value of the abcdefgh buffer, defined in step 3 
abcdefgh; = the output of the last round of processing of the ith message 
block 
N = the number of blocks in the message (including padding and 
length fields) 
SUM,, = addition modulo 2“ performed separately on each word of the 
pair of inputs 
MD = final message digest value 


SHA-512 Round Function 


Let us look in more detail at the logic in each of the 80 steps of the processing of 
one 512-bit block (Figure 11.10). Each round is defined by the following set of 


equations: 
T, =h+ Che, fg) + (D2) + W, + K, 
Ty = (37a) + Maj(a, b,c) 
i= 8 
g=7f 
f=e 
e=dt T; 
d=c 
c=b 
b=a 
a= T; + T> 

where 

t = step number;0 = t = 79 


Ch(e, f, g) = (e AND f) ® (NOT e AND g) 
the conditional function: If e then f else g 


11.5 / SECURE HASH ALGORITHM (SHA) 


Table 11.4 SHA-512 Constants 
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428a2£98d728ae22 7137449123ef65cd b5c0fbcfec4d3b2£  e9b5dba58189dbbc 
3956c25b£348b538 59£111£1b605d019 923f82a4af194f9b ablcS5ed5da6d8118 
d807aa98a3030242 12835b0145706fbe 243185be4ee4b28c 550c7dc3d5ffb4e2 
72be5d074£27b896£ 80deb1fe3b1696b1 9bdc06a725c71235 cl9b£174c£692694 
e49b69c19ef14ad2 efbe4786384f£25e3 Ofc19dc68b8cd5b5 240calcc77ac9c65 
2de92c6£592b0275 4a7484aab6ea6e483 S5cb0a9dcbd4lfbd4 76£988da831153b5 
983e5152ee66dfab a831c66d2db43210 b00327c898fb213f bf597fc7beef0ee4 
c6e00b£E33da88£c2 d5a79147930aa725 06ca6351e003826£  142929670a0e6e70 
27b70a8546d22ffc 2e1b21385c26c926 4d2c6dfcbac42aed 53380d139d95b3dEf 
650a73548baf63de 766a0abb3c77b2a8 81c2c92e47edaee6 92722c851482353b 
a2bfe8al4cf£10364 a81a664bbc423001 c24b8b70d0f89791 c76c51a30654be30 
d192e819d6ef5218 d69906245565a910 £40¢35855771202a 106aa07032bbd1b8 
19a4c116b8d2d0c8 1e376c085141ab53  2748774cdf8eeb99 34b0bcb5e19b48a8 
391c0cb3c5c95a63 4ed8aa4ae3418acb 5b9cca4£7763e373 682e6fF3d6b2b8a3 
748£82ee5defb2fc 78a5636£43172£60  84c87814alf0ab72 8cc702081a6439ec 
90befffa23631e28 a4506cebde82bde9 bef9a3f7b2c67915 c67178£2e372532b 
ca273eceea26619c d186b8c721c0c207 eada7dd6écde0eble £57d4£7£ee6ed178 
06£067aa72176fba Oa637dc5a2c898a6 113f9804bef90dae 1b6710b35131c471b 
28db77£523047d84 32caab7b40c72493 3c9ebe0al5c9bebc 431d67c49c100d4c 
4cc5d4bech3e42b6 597£299cfc657e2a 5fcbéfab3ad6faec 6c44198c4a475817 


Maj(a, b, c) = (a AND b) @® (a AND c) @ (b AND c) 


(X04) 
(Sie) 


the function is true only of the majority (two or three) of the 
arguments are true 


= ROTR”**(a) @ ROTR™(a) @ ROTR*(a) 
= ROTR(e) @ ROTR!*(e) @ ROTR“(e) 


ROTR"(x) = circular right shift (rotation) of the 64-bit argument x by n bits 


W, = a 64-bit word derived from the current 512-bit input block 
K, = a 64-bit additive constant 
+ = addition modulo 2“ 


Two observations can be made about the round function. 


Six of the eight words of the output of the round function involve simply per- 
mutation (5, c, d, f, g,h) by means of rotation. This is indicated by shading in 
Figure 11.10. 


Only two of the output words (a, e) are generated by substitution. Word e is a 
function of input variables (d, e, f, g, 4), as well as the round word W, and the 
constant K,. Word a is a function of all of the input variables except d, as well 
as the round word W, and the constant K;,. 
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~t 512 bits: > 


Figure 11.10 Elementary SHA-512 Operation (single round) 


It remains to indicate how the 64-bit word values W, are derived from the 
1024-bit message. Figure 11.11 illustrates the mapping. The first 16 values of W, are 
taken directly from the 16 words of the current block. The remaining values are 
defined as 


i o7?(W,-2) +W,-7+0.-(W,-15)+W-16 
where 
o9°(x) = ROTR'(x) @ ROTR*(x) @ SHR7(x) 
o}7(x) = ROTR(x) @ ROTR* (x) @ SHR*(x) 
ROTR"(x) = circular right shift (rotation) of the 64-bit argument x by n bits 
SHR"(x) = left shift of the 64-bit argument x by n bits with padding by 


zeros on the right 
+ = addition modulo 2™ 


—+W_______— 1024 bits ———————_» Wp Wi Wo Wi4 Wi-16 Wi-1s Wi-7 Wi-2 Wo3 Wes W121 Wr 
M; 
Wo Wi eee Wis Wi6 eee eee W79 


+> 
64 bits 
Figure 11.11 Creation of 80-word Input Sequence for SHA-512 Processing of Single Block 
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Thus, in the first 16 steps of processing, the value of W, is equal to the corre- 
sponding word in the message block. For the remaining 64 steps, the value of W, 
consists of the circular left shift by one bit of the XOR of four of the preceding 
values of W,, with two of those values subjected to shift and rotate operations. This 
introduces a great deal of redundancy and interdependence into the message blocks 
that are compressed, which complicates the task of finding a different message 
block that maps to the same compression function output. 

Figure 11.12 summarizes the SHA-512 logic. 

The SHA-512 algorithm has the property that every bit of the hash code is a 
function of every bit of the input. The complex repetition of the basic function F 
produces results that are well mixed; that is, it is unlikely that two messages chosen 
at random, even if they exhibit similar regularities, will have the same hash code. 
Unless there is some hidden weakness in SHA-512, which has not so far been 
published, the difficulty of coming up with two messages having the same message 
digest is on the order of 2”°° operations, while the difficulty of finding a message 
with a given digest is on the order of 2°”? operations. 


Example 


We include here an example based on one in FIPS 180. We wish to hash a one-block 
message consisting of three ASCII characters: “abc”, which is equivalent to the fol- 
lowing 24-bit binary string: 


01100001 01100010 01100011 


Recall from step 1 of the SHA algorithm, that the message is padded to a 
length congruent to 896 modulo 1024. In this case of a single block, the padding 
consists of 896 — 24 = 872bits, consisting of a “1” bit followed by 871 “0” bits. 
Then a 128-bit length value is appended to the message, which contains the length 
of the original message (before the padding). The original length is 24 bits, or a 
hexadecimal value of 18. Putting this all together, the 1024-bit message block, in 
hexadecimal, is 


6162638000000000 0000000000000000 0000000000000000 0000000000000000 
0000000000000000 0000000000000000 0000000000000000 0000000000000000 
0000000000000000 0000000000000000 0000000000000000 0000000000000000 
0000000000000000 0000000000000000 0000000000000000 0000000000000018 


This block is assigned to the words WO, ...,W15 of the message schedule, 
which appears as follows. 


Wo = 6162638000000000 Ws = 0000000000000000 
W, = 0000000000000000 W6 = 0000000000000000 
W, = 0000000000000000 W-, = 0000000000000000 
W3 = 0000000000000000 Ws = 0000000000000000 


W,4 = 0000000000000000 Wo = 0000000000000000 
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Wi = 0000000000000000 
Wi, = 0000000000000000 
W,2 = 0000000000000000 


W,3 = 0000000000000000 
Wi4 = 0000000000000000 
W,5 = 0000000000000018 
As indicated in Figure 11.12, the eight 64-bit variables, a through h, are initial- 


ized to values Hoo through Ho 7. The following table shows the initial values of these 
variables and their values after each of the first two rounds. 


a 6a09e667£3bcc908 f6afceb8bcfcdd£5 1320£8c9£b872cc0 
b bb67ae8584caa73b 6a09e667£3bcc908 feafceb8bcfcdd£5 
c 3c6ef372£e94F82b bb67ae8584caa73b 6a09e667£3bcc908 
d a54ff£53a5f1d36f1 3c6ef372£e94F82b bb67ae8584caa73b 
e 510e527fade682d1 58cb02347ab51£91 c3d4ebfd48650ffa 
£ 9b05688c2b3e6cl1£f 510e527fade682d1 58cb02347ab51£91 
g 1£83d9abfb41bd6b 9b05688c2b3e6c1£ 510e527fade682d1 
h 5be0cd19137e2179 1£83d9abfb41bd6b 9b05688c2b3e6cl1£ 


Note that in each of the rounds, six of the variables are copied directly from 
variables from the preceding round. 
The process continues through 80 rounds. The output of the final round is 


73a54f399fa4b1b2 10d9c4c4295599f6 d67806db8b148677 654ef9%abec389ca9 
d08446aa79693ed7 9bb4d39778c07E£9e 25c96a7768Eb2aa3 ceb9Fc3691ce8326 


The hash value is then calculated as 


Ho = 6a09e667£3bcc908 + 73a54£399Fa4b1b2 = ddaf35al193617aba 


Hy, = bb67ae8584caa73b + 10d9c4c4295599f6 = cc417349ae204131 


Hy. = 3c6ef372£e94F82b + d67806db8b148677 = 12e6fa4e89a9Tea2 


Hy 3 = a54££53a5f1d36f1 + 654ef9abec389ca9 = Vadeeee64b55d39a 


4 = 510e527fade682d1 + d08446aa79693ed7 = 2192992a274fcl1a8 


Hy 5 = 9b05688c2b3e6c1f£ + 9bb4d39778c07£9e = 36ba3c23a3 feebbd 
F165 = 1£83d9abfb41bd6b + 25c96a7768Fb2aa3 = 454d4423643ce80e 


Hy7 = 5be0cd19137e2179 + ceb9fc3691ce8326 = 2a9ac9I4Fa54ca4gFt 


The resulting 512-bit message digest is 


ddaf35a193617aba cc417349ae204131 12ec6fa4e89a9T7ea2 Oa9eeee64b55d39a 
2192992a274fcla8 36ba3c23a3feebbd 454d4423643ce80e 2aIac94fab4ca49F 
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The padded message consists blocks My, Mo, ..., My. Each message block M; 


consists of 16 64-bit words Mj, Mj 1, ...,Mj15. All addition is performed 
modulo 2%. 


Ho = 6A09E667F3BCC908 Ho 4 = S10ES27FADE682D1 

Ho, = BB67AE8584CAA73B Ho 5 = 9B05688C2B3E6C1F 

Ho2 = 3C6EF372FE94F82B Ho = 1F83D9ABFB41BD6B 

Ho3 = AS4FFS3A5F1D36F1 Ho7 = SBEOCDI9137E2179 
fori =1toN 

Prepare the message schedule W 

for t = 0 to 15 

W, = Mit 


for t = 16 to 79 
W, = fonts (W,-2) ats W,-7 a6 aay (W,-15) oF W.-16 


Initialize the working variables 


a= H;j4 as Pep 
i 3 Osa if = Has 
eee oF Wy) 6 = Bete 
eg Fare each) 


Perform the main hash computation 
for t = 0 to 79 


T\= h+ Ch(e,f,g) + (S"e) ay ke 


To= ( Si") + Maj(a, b,c) 


a8 

ee 

f =e 

e =d+ T; 

d=c 

c=b 

b =a 

a Ti ap T> 
Compute the inermediate hash value 
Hijo = a+ Hp Hig = a+ Aig 
Hy = a+ Ay ys = a+ Ay45 
Hy = 1 45 Aj42 Fi = (015 Fii6 
Ay3 =a+ Hi13 Ay7 = a+ Hia7 


return {Hn0 ll Any ll Hy2 ll Ayn3 ll Anas ll Ay 5 ll An 6 ll Ay 7} 


SHA-512 Logic 
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Suppose now that we change the input message by one bit, from “abc” to 
“cbc”. Then, the 1024-bit message block is 


6362638000000000 
0000000000000000 
0000000000000000 
0000000000000000 


0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 


0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 


And the resulting 512-bit message digest is 


531668966ee79b70 0b68e593261101354 4273 £7ef7b31£279 
319c165ad96d9187 55e6a204c2607e27 6e05cd£993a64c85 


0000000000000000 
0000000000000000 
0000000000000000 
0000000000000018 


2a7ef£68d53 £93264 
ef9elel25c0f925£ 


The number of bit positions that differ between the two hash values is 253, 
almost exactly half the bit positions, indicating that SHA-512 has a good avalanche 
effect. 


11.6 SHA-3 


As of this writing, SHA-1 has not yet been “broken.” That is, no one has demonstrated 
a technique for producing collisions in less than brute-force time. However, because 
SHA-1 is very similar in structure and in the basic mathematical operations used to 
MDS and SHA-0, both of which have been broken, SHA-1 is considered insecure and 
has been phased out for SHA-2. 

SHA-2, particularly the 512-bit version, would appear to provide unassailable 
security. However, SHA-2 shares the same structure and mathematical operations 
as its predecessors, and this is a cause for concern. Because it will take years to find 
a suitable replacement for SHA-2, should it become vulnerable, NIST decided to 
begin the process of developing a new hash standard. 

Accordingly, NIST announced in 2007 a competition to produce the next 
generation NIST hash function, to be called SHA-3. NIST would like to have a new 
standard in place by the end of 2012, but emphasizes that this is not a fixed timeline 
and that the schedule could slip well beyond that date. The basic requirements that 
must be satisfied by any candidate for SHA-3 are the following. 


1. It must be possible to replace SHA-2 with SHA-3 in any application by a simple 
drop-in substitution. Therefore, SHA-3 must support hash value lengths of 224, 
256, 384, and 512 bits. 


SHA-3 must preserve the online nature of SHA-2. That is, the algorithm must 
process comparatively small blocks (512 or 1024 bits) at a time instead of 
requiring that the entire message be buffered in memory before processing it. 


nN 


Beyond these basic requirements, NIST has defined a set of evaluation criteria. 
These criteria are designed to reflect the requirements for the main applications sup- 
ported by SHA-2, which include digital signatures, hashed message authentication 
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codes, key generation, and pseudorandom number generation. The evaluation crite- 
ria for the new hash function, in decreasing order of importance, are as follows. 


e Security: The security strength of SHA-3 should be close to the theoretical 
maximum for the different required hash sizes and for both preimage resis- 
tance and collision resistance. SHA-3 algorithms must be designed to resist 
any potentially successful attack on SHA-2 functions. In practice, this probably 
means that SHA-3 must be fundamentally different than the SHA-1, SHA-2, 
and MDS algorithms in either structure, mathematical functions, or both. 


e Cost: SHA-3 should be both time and memoty efficient over a range of hard- 
ware platforms. 


e Algorithm and implementation characteristics: Consideration will be given 
to such characteristics as flexibility (e.g., tunable parameters for security/ 
performance tradeoffs, opportunity for parallelization, and so on) and simplic- 
ity. The latter characteristic makes it easier to analyze the security properties 
of the algorithm 


11.7 RECOMMENDED READING AND WEB SITES 


[PREN99] is a good survey of cryptographic hash functions. [GILB03] examines the security 
of SHA-256 through SHA-512. 


GILB03 Gilbert, H. and Handschuh, H. “Security Analysis of SHA-256 and Sisters.” 
“Proceedings, CRYPTO ’03, 2003; published by Springer-Verlag. 


PREN99 Preneel, B. “The State of Cryptographic Hash Functions.” Proceedings, EURO- 
CRYPT ’96, 1996; published by Springer-Verlag. 


Recommended Web Sites: 


e NIST Secure Hashing Page: SHA FIPS and related documents. 


e Cryptographic Hash Algorithm Competition: NIST page on its competition 
for a new standardized hash algorithm, to be called SHA-3. 
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Key Terms 


big endian birthday paradox compression function 
birthday attack collision resistant cryptographic hash function 
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hash code 
hash function 
hash value 


keyed hash function 
little endian 
message authentication code 


MD4 

MD5 

message digest 

one-way hash function 
preimage resistant 
second preimage resistant 


SHA-224 

SHA-256 

SHA-384 

SHA-512 

strong collision resistance 
weak collision resistance 


SHA-1 


(MAC) 


Review Questions 


11.1 What characteristics are needed in a secure hash function? 

11.2 What is the difference between weak and strong collision resistance? 
11.3. What is the role of a compression function in a hash function? 

11.4 What is the difference between little-endian and big-endian format? 
11.5 What basic arithmetical and logical functions are used in SHA? 


Problems 


11.1 The high-speed transport protocol XTP (Xpress Transfer Protocol) uses a 32-bit 
checksum function defined as the concatenation of two 16-bit functions: XOR and 
RXOR, defined in Section 11.4 as “two simple hash functions” and illustrated in 

Figure 11.4. 

a. Will this checksum detect all errors caused by an odd number of error bits? 

Explain. 

b. Will this checksum detect all errors caused by an even number of error bits? If 
not, characterize the error patterns that will cause the checksum to fail. 

c. Comment on the effectiveness of this function for use as a hash function for 
authentication. 

11.2 a. Consider the Davies and Price hash code scheme described in Section 11.4 and 

assume that DES is used as the encryption algorithm: 


A; = Hj-1 ® E(Mi, H-1) 
Recall the complementarity property of DES (Problem 3.14): If Y = E(K, X), 
then Y’ = E(K’, X’). Use this property to show how a message consisting of 


blocks M,, Mo, ..., My can be altered without altering its hash code. 
b. Show that a similar attack will succeed against the scheme proposed in [MEYES838]: 


H, = M;® E(H;-4, Mj) 
11.3 a. Consider the following hash function. Messages are in the form of a sequence of 
t 
.a,). The hash value / is calculated as (S4) for 


isl 
some predefined value n. Does this hash function satisfy any of the requirements 


numbers in Z,, M = (aj, a, .. 


for a hash function listed in Table 11.1? Explain your answer. 


t 
b. Repeat part (a) for the hash function h = ( py (a)") mod n. 
i=1 


c. Calculate the hash function of part (b) for M = (189, 632, 900, 722, 349) and 
n = 989. 
11.4 It is possible to use a hash function to construct a block cipher with a structure similar 
to DES. Because a hash function is one way and a block cipher must be reversible (to 
decrypt), how is it possible? 


11.5 


11.6 


11.7 


11.8 
11.9 


11.10 


11.11 


11.12 
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Now consider the opposite problem: using an encryption algorithm to construct a one- 
way hash function. Consider using RSA with a known key. Then process a message 
consisting of a sequence of blocks as follows: Encrypt the first block, XOR the result 
with the second block and encrypt again, etc. Show that this scheme is not secure by 
solving the following problem. Given a two-block message B1, B2, and its hash 


RSAH(B;, B)) = RSA(RSA(B1) @ B2) 


Given an arbitrary block C1, choose C2 so that RSAH(C1, C2) = RSAH(B1, B2). Thus, 
the hash function does not satisfy weak collision resistance. 

Suppose H(m) is a collision-resistant hash function that maps a message of arbitrary 
bit length into an n-bit hash value. Is it true that, for all messages x, x’ with x # x’, we 
have H(x) # H(x') Explain your answer. 

In Figure 11.11, it is assumed that an array of 80 64-bit words is available to store the 
values of W,, so that they can be precomputed at the beginning of the processing of a 
block. Now assume that space is at a premium. As an alternative, consider the use of a 
16-word circular buffer that is initially loaded with Wp through W;,;. Design an algo- 
rithm that, for each step ft, computes the required input value W,. 

For SHA-512, show the equations for the values of W16, W17, Wi, and Wyo. 

State the value of the padding field in SHA-512 if the length of the message is 

a. 1919 bits 

b. 1920 bits 

c. 1921 bits 

State the value of the length field in SHA-512 if the length of the message is 

a. 1919 bits 

b. 1920 bits 

c. 1921 bits 

Suppose a,aza3a,4 are the 4 bytes in a 32-bit word. Each a; can be viewed as an integer 
in the range 0 to 255, represented in binary. In a big-endian architecture, this word 
represents the integer 


a,2*4 ap2'6 a328 a4 


In a little-endian architecture, this word represents the integer 
ay2* + a,2!° + 2,28 + a, 

a. Some hash functions, such as MDS, assume a little-endian architecture. It is impor- 
tant that the message digest be independent of the underlying architecture. 
Therefore, to perform the modulo 2 addition operation of MDS or RIPEMD-160 
on a big-endian architecture, an adjustment must be made. Suppose X = xj X7X3X4 
and Y = y,y2y3y4. Show how the MDS addition operation (X + Y) would be 
carried out on a big-endian machine. 

b. SHA assumes a big-endian architecture. Show how the operation (X + Y) for 
SHA would be carried out on a little-endian machine. 


This problem introduces a hash function similar in spirit to SHA that operates on 
letters instead of binary data. It is called the toy tetragraph hash (tth).? Given a mes- 
sage consisting of a sequence of letters, tth produces a hash value consisting of four 
letters. First, tth divides the message into blocks of 16 letters, ignoring spaces, punctu- 
ation, and capitalization. If the message length is not divisible by 16, it is padded out 
with nulls. A four-number running total is maintained that starts out with the value 
(0, 0, 0, 0); this is input to the compression function for processing the first block. 
The compression function consists of two rounds. 


Round 1 Get the next block of text and arrange it as a row-wise 4 X 4 block of text 


and covert it to numbers (A = 0,B = 1, etc.). For example, for the block 
ABCDEFGHIJKLMNOP, we have 


71 thank William K. Mason, of the magazine staff of The Cryptogram, for providing this example. 
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A/|B|C/]D 0; 1 );2 4) 3 
E|F|G/H 4)/5|6]7 
I] J/K/L 8 | 9 | 10} 11 
M|N|O} P 12 | 13 | 14] 15 


Then, add each column mod 26 and add the result to the running total, mod 26. In 
this example, the running total is (24, 2, 6, 10). 

Round 2 Using the matrix from round 1, rotate the first row left by 1, second row left by 2, 
third row left by 3, and reverse the order of the fourth row. 
In our example: 


B|C;/D|A 1} 24)3 4 0 
G|H|E]|F 6|7/445 
L|I|J|K 11} 8 | 9 | 10 
P|/O|N/|M 15) 14) 13] 12 


Now, add each column mod 26 and add the result to the running total. The new 
running total is (5,7, 9, 11). This running total is now the input into the first round 
of the compression function for the next block of text. After the final block is 
processed, convert the final running total to letters. For example, if the message is 
ABCDEFGHIJKLMNOP, then the hash is FHJL. 

a. Draw figures comparable to Figures 11.8 and 11.9 to depict the overall tth logic 
and the compression function logic. 

b. Calculate the hash function for the 48-letter message “I leave twenty million dol- 
lars to my friendly cousin Bill.” 

c. To demonstrate the weakness of tth, find a 48-letter block that produces the same 
hash as that just derived. Hint: Use lots of A’s. 


The remaining problems deal with the hash function Whirlpool, described in Appendix N. 

11.13. Develop a table similar to Table 4.9 for GF(2°) with m(x) = x8 + x4 + x + x? +1. 

11.14 Show the E and E™! mini-boxes in Table N.2 in the traditional S-box square matrix 
format, such as that of Table 5.4. 

11.15 Verify that Figure N.5 is a valid implementation of the S-box shown in Table N.2a. Do 
this by showing the calculations involved for three input values: 00, 55, 1E. 


11.16 Provide a Boolean expression that defines the S-box functionality of Figure N.5. 


11.17 Whirlpool makes use of the construction H; = E(H;-1, M;) ® Hi-1 ® Mj. Another 
construction that was shown by Preneel to be secure is H; = E(H;_1, M;) ® M;.Now 
notice that the key schedule for Whirlpool resembles encryption of the cipher key 
under a pseudo-key defined by the round constants, so that the core of the hashing 
process could be formally viewed as two interacting encryption lines. Consider the 
encryption E(H;_,;,M;). We could write the final round key for this block as 
Kyo = E(RC, H;_1). Now show that the two hash constructions are essentially equiv- 
alent because of the way that the key schedule is defined. 


APPENDIX 114A MATHEMATICAL BASIS OF THE BIRTHDAY 


ATTACK 


In this appendix, we derive the mathematical justification for the birthday attack. 
We begin with a related problem and then look at the problem from which the name 
“birthday attack” is derived. 
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Related Problem 


A general problem relating to hash functions is the following. Given a hash func- 
tion H, with n possible outputs and a specific value H(x), if H is applied to k ran- 
dom inputs, what must be the value of k so that the probability that at least one 
input y satisfies H(y) = H(x) is 0.5? 

For a single value of y, the probability that H(y) = H(x) is just 1/n. 
Conversely, the probability that H(y) # H(x) is [1 — (1/n)]. If we generate k ran- 
dom values of y, then the probability that none of them match is just the product of 
the probabilities that each individual value does not match, or [1 — (1/n)]*. Thus, the 
probability that there is at least one match is 1 — [1 — (1/n)]*. 

The binomial theorem can be stated as 


(1 —a)k=1-—kat ae 5 eae 1 
2! 3! 


For very small values of a, this can be approximated as (1 — ka).Thus, the probabil- 
ity of at least one match is approximated as 1 — [1 — (1/n)]k ~ 
1 — [1 — (k/n)] = k/n. For a probability of 0.5, we have k = n/2. 

In particular, for an m-bit hash code, the number of possible codes is 2” and 
the value of k that produces a probability of one-half is 


k = 2-) (11.1) 


The Birthday Paradox 


The birthday paradox is often presented in elementary probability courses to 
demonstrate that probability results are sometimes counterintuitive. The prob- 
lem can be stated as follows. What is the minimum value of k such that the prob- 
ability is greater than 0.5 that at least two people in a group of k people have the 
same birthday? Ignore February 29 and assume that each birthday is equally 
likely. 

We can reason to the answer as follows. The probability that the birthdays 
of any two people are not alike is clearly 364/365 (since there is only one chance 
in 365 that one person’s birthday will coincide with another’s). The probability 
that a third person’s birthday will differ from the other two is 363/365; a fourth 
person’s, 362/365; and so on, until we reach the 24th person (342/365). We thus 
obtain a series of 23 fractions which must be multiplied together to reach the 
probability that all 24 birthdays are different. The product is a fraction that 
reduces to about 0.507, or slightly better than 1/2, for a coincidence among 23 
people. 

To derive this answer formally, let us define 

P(n, k) = Pr[at least one duplicate in k items, with each item able to take on 

one of n equally likely values between 1 and n 

Thus, we are looking for the smallest value of k such that P(365, k) = 0.5. It is 
easier first to derive the probability that there are no duplicates, which we designate 
as Q(365, k). If k > 365, then it is impossible for all values to be different. So we 
assume k = 365. Now consider the number of different ways, N, that we can have k 
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values with no duplicates. We may choose any of the 365 values for the first item, any 
of the remaining 364 numbers for the second item, and so on. Hence, the number of 
different ways is 


] 
N = 365 X 364 X ... (365 -— +1) =—— (11.2) 
(365 — k)! 

If we remove the restriction that there are no duplicates, then each item can be 
any of 365 values, and the total number of possibilities is 365*. So the probability of 
no duplicates is simply the fraction of sets of values that have no duplicates out of all 
possible sets of values: 


365!/(365 — k)! 365! 
365, k) = = 
aon) (365)* (365 — k)!(365)* 
and 
! 
P(365, k) = 1 — Q(365,k) = 1 = (11.3) 


(365 — k)!(365)* 


This function is plotted in Figure 11.13. The probabilities may seem surpris- 
ingly large to anyone who has not considered the problem before. Many people 
would guess that to have a probability greater than 0.5 that there is at least one 
duplicate, the number of people in the group would have to be about 100. In fact, the 
number is 23, with P(365, 23) = 0.5073. For k = 100, the probability of at least one 
duplicate is 0.9999997. 


P(365, k) 
-) 
in 


0.0 


0 10 20 30 40 50 60 70 


Figure 11.13 The Birthday Paradox 
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Perhaps the reason that the result seems so surprising is that if you consider a 
particular person in a group, the probability that some other person in the group has 
the same birthday is small. But the probability that we are concerned with is the 
probability that any pair of people in the group has the same birthday. In a group of 
23, there are (23(23 — 1))/2 = 253 different pairs of people. Hence the high proba- 
bilities. 


Useful Inequality 


Before developing a generalization of the birthday problem, we derive an inequality 
that will be needed: 


(1—-—x)se™ forallx =0 (11.4) 


Figure 11.14 illustrates the inequality. To see that the inequality holds, note that 
the lower line is the tangent to e * at x = 0.The slope of that line is just the derivative 
ofe “atx = 0: 


fx) =e* 
d 
f(a) = Ge* =e" 
FO)= —-1 
The tangent is a straight line of the form ax + b with a = —1, and the tangent 


at x = 0 must equal e ° = 1. Thus, the tangent is the function (1 — x), confirming 
the inequality of Equation (11.4). Furthermore, note that for small x, we have 
(1-x)se™. 


0.0 | | | | 
0.0 0.2 0.4 0.6 0.8 1.0 


Figure 11.14 A Useful Inequality 
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The General Case of Duplications 


The birthday problem can be generalized to the following problem. Given a random 
variable that is an integer with uniform distribution between 1 and n and a selection 
of k instances (kK = n) of the random variable, what is the probability, P(n, k), that 
there is at least one duplicate? The birthday problem is just the special case with 
n = 365. By the same reasoning as before, we have the following generalization of 
Equation (11.3): 

n!} 


P(n, k) = 1 eae (11.5) 


We can rewrite this as 


nX(n—-—1)X +: X(n-—k+1) 


P(n,k) =1 


1 x x x BOEST) 


nile Bont) 


Using the inequality of Equation (11.4), 


P(n, k) >1- [(e" 1”) x (e~2") SC aaa SC (e-&Diry] 
>l-e [(/n)+(2/n)+...+((k-1)/n)] 


S 1 — eT (kXK-D)/2n 


Now let us pose the question: What value of k is required such that P(n, k) > 
0.5? To satisfy the requirement, we have 


1/2 =1- e (kx (k-1))/2n 
a= e(kx(k-1))/2n 
_ kx (k-1) 
2n 


In2 


For large k, we can replace k X (k — 1) by k*,and we get 
k = V2(in2)n = 1.18Vn ~ Vn (11.6) 


As a reality check, for n = 365, we get k = 1.18 X V365 = 22.54, which is 
very close to the correct answer of 23. 

We can now state the basis of the birthday attack in the following terms. 
Suppose we have a function H, with 2” possible outputs (i.e., an m-bit output). If 
H is applied tok random inputs, what must be the value of k so that there is the 
probability of at least one duplicate [i.e., H(x) = H(y) for some inputs x, y)]? 
Using the approximation in Equation (11.6), 


k= V2" = qin/2 (11.7) 
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Overlap between Two Sets 


There is a problem related to the general case of duplications that is also of rele- 
vance for our discussions. The problem is this: Given an integer random variable 
with uniform distribution between 1 and n and two sets of k instances (k = n) of the 
random variable, what is the probability, R(n, k), that the two sets are not disjoint; 
that is, what is the probability that there is at least one value found in both sets? 

Let us call the two sets X and Y, with elements {x,,%, ...,x,} and 
{v1,¥2, ---5¥xz}, respectively. Given the value of x,, the probability that y, = x, is 
just 1/n, and therefore the probability that y, does not match x, is [1 — (1/n)]. If we 
generate the k random values in Y, the probability that none of these values is equal 
to x, is [1 — (1/n)]*. Thus, the probability that there is at least one match to x, is 
1 — [1 - (mn). 

To proceed, let us make the assumption that all the elements of X are distinct. 
If n is large and if k is also large (e.g., on the order of Vn), then this is a good 
approximation. In fact, there may be a few duplications, but most of the values will 
be distinct. With that assumption, we can make the following derivation: 


1 k 
Pr[no match in Y to x] = (1 - 1) 
n 


1 k\k 1 kb 
Pr[no match in Y to X] = (: ) = (1 ) 
n n 


ie 
R(a, k) = Pr[at least one match in Y to X] = 1 — (1 - ~) 


Using the inequality of Equation (11.4), 

R(n, k) > 1 - (e")F 

R(n, k) > 1 - (e*/") 
Let us pose the question: What value of & is required such that R(n, k) > 0.5? To sat- 
isfy the requirement, we have 


1/2=1-(e**) 


2 = kin 
ke 
In(2) = a 
k = Vdn(2))n = 0.83Vn © Vian (11.8) 


We can state this in terms related to birthday attacks as follows. Suppose we have 
a function H with 2” possible outputs (i.e., an m-bit output). Apply H to k random 
inputs to produce the set X and again to & additional random inputs to produce the set 
Y. What must be the value of k so that there is the probability of at least 0.5 that there is 
a match between the two sets (i.e., H(x) = H(y) for some inputs x € X, y e Y)? Using 
the approximation in Equation (11.8): 


ka VP? = 27" 
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At cats’ green on the Sunday he took the message from the inside of the pillar 
and added Peter Moran’s name to the two names already printed there in 
the “Brontosaur” code. The message now read: “Leviathan to Dragon: Martin 
Hillman, Trevor Allan, Peter Moran: observe and tail.” What was the good of it 
John hardly knew. He felt better, he felt that at last he had made an attack on 
Peter Moran instead of waiting passively and effecting no retaliation. Besides, 
what was the use of being in possession of the key to the codes if he never took 
advantage of it? 


—Talking to Strange Men, Ruth Rendell 


KEY POINTS 


® Message authentication is a mechanism or service used to verify the 
integrity of a message. Message authentication assures that data received 
are exactly as sent by (i.e., contain no modification, insertion, deletion, or 
replay) and that the purported identity of the sender is valid. 


® Symmetric encryption provides authentication among those who share the 
secret key. 


® A message authentication code (MAC) is an algorithm that requires the 
use of a secret key. A MAC takes a variable-length message and a secret 
key as input and produces an authentication code. A recipient in posses- 
sion of the secret key can generate an authentication code to verify the 
integrity of the message. 

® One means of forming a MAC is to combine a cryptographic hash function 
in some fashion with a secret key. 

® Another approach to constructing a MAC is to use a symmetric block 


cipher in such a way that it produces a fixed-length output for a variable- 
length input. 


One of the most fascinating and complex areas of cryptography is that of message 
authentication and the related area of digital signatures. It would be impossible, in 
anything less than book length, to exhaust all the cryptographic functions and pro- 
tocols that have been proposed or implemented for message authentication and dig- 
ital signatures. Instead, the purpose of this chapter and the next is to provide a broad 
overview of the subject and to develop a systematic means of describing the various 
approaches. 

This chapter begins with an introduction to the requirements for authentica- 
tion and digital signature and the types of attacks to be countered. Then the basic 
approaches are surveyed. The remainder of the chapter deals with the fundamental 
approach to message authentication known as the message authentication code 
(MAC). Following an overview of this topic, the chapter looks at security considera- 
tions for MACs. This is followed by a discussion of specific MACs in two categories: 
those built from cryptographic hash functions and those built using a block cipher 
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mode of operation. Next, we look at a relatively recent approach known as authen- 
ticated encryption. Finally, we look at the use of cryptographic hash functions and 
MACs for pseudorandom number generation. 


12.1 MESSAGE AUTHENTICATION REQUIREMENTS 


In the context of communications across a network, the following attacks can be 
identified. 


1. Disclosure: Release of message contents to any person or process not possess- 
ing the appropriate cryptographic key. 


nN 


Traffic analysis: Discovery of the pattern of traffic between parties. In a 
connection-oriented application, the frequency and duration of connections 
could be determined. In either a connection-oriented or connectionless environ- 
ment, the number and length of messages between parties could be determined. 


3. Masquerade: Insertion of messages into the network from a fraudulent source. 
This includes the creation of messages by an opponent that are purported to 
come from an authorized entity. Also included are fraudulent acknowledg- 
ments of message receipt or nonreceipt by someone other than the message 
recipient. 


4. Content modification: Changes to the contents of a message, including insertion, 
deletion, transposition, and modification. 


5. Sequence modification: Any modification to a sequence of messages between 
parties, including insertion, deletion, and reordering. 


6. Timing modification: Delay or replay of messages. In a connection-oriented 
application, an entire session or sequence of messages could be a replay of some 
previous valid session, or individual messages in the sequence could be delayed 
or replayed. In a connectionless application, an individual message (e.g., data- 
gram) could be delayed or replayed. 


7. Source repudiation: Denial of transmission of message by source. 


8. Destination repudiation: Denial of receipt of message by destination. 


Measures to deal with the first two attacks are in the realm of message confi- 
dentiality and are dealt with in Part One. Measures to deal with items (3) through 
(6) in the foregoing list are generally regarded as message authentication. 
Mechanisms for dealing specifically with item (7) come under the heading of digital 
signatures. Generally, a digital signature technique will also counter some or all of 
the attacks listed under items (3) through (6). Dealing with item (8) may require a 
combination of the use of digital signatures and a protocol designed to counter this 
attack. 

In summary, message authentication is a procedure to verify that received 
messages come from the alleged source and have not been altered. Message 
authentication may also verify sequencing and timeliness. A digital signature is an 
authentication technique that also includes measures to counter repudiation by the 
source. 
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12.2 MESSAGE AUTHENTICATION FUNCTIONS 


Any message authentication or digital signature mechanism has two levels of func- 
tionality. At the lower level, there must be some sort of function that produces an 
authenticator: a value to be used to authenticate a message. This lower-level func- 
tion is then used as a primitive in a higher-level authentication protocol that enables 
a receiver to verify the authenticity of a message. 

This section is concerned with the types of functions that may be used to pro- 
duce an authenticator. These may be grouped into three classes. 


e Hash function: A function that maps a message of any length into a fixed- 
length hash value, which serves as the authenticator 


e Message encryption: The ciphertext of the entire message serves as its authen- 
ticator 


e Message authentication code (MAC): A function of the message and a secret 
key that produces a fixed-length value that serves as the authenticator 


Hash functions, and how they may serve for message authentication, are dis- 
cussed in Chapter 11. The remainder of this section briefly examines the remaining 
two topics. The remainder of the chapter elaborates on the topic of MACs. 


Message Encryption 


Message encryption by itself can provide a measure of authentication. The analysis 
differs for symmetric and public-key encryption schemes. 


SYMMETRIC ENCRYPTION Consider the straightforward use of symmetric encryption 
(Figure 12.1a). A message M transmitted from source A to destination B is 
encrypted using a secret key K shared by A and B. If no other party knows the key, 
then confidentiality is provided: No other party can recover the plaintext of the 
message. 

In addition, B is assured that the message was generated by A. Why? The mes- 
sage must have come from A, because A is the only other party that possesses K and 
therefore the only other party with the information necessary to construct cipher- 
text that can be decrypted with K. Furthermore, if M is recovered, B knows that 
none of the bits of M have been altered, because an opponent that does not know K 
would not know how to alter bits in the ciphertext to produce the desired changes in 
the plaintext. 

So we may say that symmetric encryption provides authentication as well as 
confidentiality. However, this flat statement needs to be qualified. Consider exactly 
what is happening at B. Given a decryption function D and a secret key K, the 
destination will accept any input X and produce output Y = D(K, X). If X is the 
ciphertext of a legitimate message M produced by the corresponding encryption 
function, then Y is some plaintext message M. Otherwise, Y will likely be a 
meaningless sequence of bits. There may need to be some automated means of 
determining at B whether Y is legitimate plaintext and therefore must have come 
from A. 
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~«<— Source A ———> =<— Destination B ——~ 
, o—|]}-—_-9—. i 
K E(K, M) K 


(a) Symmetric encryption: confidentiality and authentication 


PU, E(PU,, M) PR, 


(b) Public-key encryption: confidentiality 


PR E(PRa, M) PU, 


a 


(c) Public-key encryption: authentication and signature 


Terie: 


pr, E(PRa,M) py, E(PU;.E(PRa,M)) pp, E(PRa,M) py 


x 


(d) Public-key encryption: confidentiality, authentication, and signature 


Figure 12.1 Basic Uses of Message Encryption 


The implications of the line of reasoning in the preceding paragraph are pro- 
found from the point of view of authentication. Suppose the message M can be any 
arbitrary bit pattern. In that case, there is no way to determine automatically, at the 
destination, whether an incoming message is the ciphertext of a legitimate message. 
This conclusion is incontrovertible: If M can be any bit pattern, then regardless of 
the value of X, the value Y = D(K, X) is some bit pattern and therefore must be 
accepted as authentic plaintext. 

Thus, in general, we require that only a small subset of all possible bit pat- 
terns be considered legitimate plaintext. In that case, any spurious ciphertext is 
unlikely to produce legitimate plaintext. For example, suppose that only one bit 
pattern in 10° is legitimate plaintext. Then the probability that any randomly cho- 
sen bit pattern, treated as ciphertext, will produce a legitimate plaintext message 
is only 10°°. 

For a number of applications and encryption schemes, the desired conditions 
prevail as a matter of course. For example, suppose that we are transmitting English- 
language messages using a Caesar cipher with a shift of one (K = 1). A sends the 
following legitimate ciphertext: 


nbsftfbupbutboeepft fbhupbutboemjuumfmbnct fbhujwz 
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B decrypts to produce the following plaintext: 
mareseatoatsanddoeseatoatsandlittlelambseativy 


A simple frequency analysis confirms that this message has the profile of ordinary 
English. On the other hand, if an opponent generates the following random 
sequence of letters: 


zuvrsoevggqxlzwigamdvnmhpmccxiuureosfbcebtqxsxg 
this decrypts to 
ytugqrndufpwkyvhfzlcumlgolbbwhttqdnreabdaspwrwp 


which does not fit the profile of ordinary English. 

It may be difficult to determine automatically if incoming ciphertext decrypts 
to intelligible plaintext. If the plaintext is, say, a binary object file or digitized X-rays, 
determination of properly formed and therefore authentic plaintext may be diffi- 
cult. Thus, an opponent could achieve a certain level of disruption simply by issuing 
messages with random content purporting to come from a legitimate user. 

One solution to this problem is to force the plaintext to have some structure 
that is easily recognized but that cannot be replicated without recourse to the 
encryption function. We could, for example, append an error-detecting code, also 
known as a frame check sequence (FCS) or checksum, to each message before 
encryption, as illustrated in Figure 12.2a. A prepares a plaintext message M and 
then provides this as input to a function F that produces an FCS. The FCS is 
appended to M and the entire block is then encrypted. At the destination, B 


=«————— Source A ——————> =«x———— Destination B ————~ 


M 


F 
[F)| : 7 FM) Compare 
K E(K, [M || F()]) K | t 


(a) Internal error control 


K E(K, M) 


E(K, M) 


7 
FE(K, M)) 


(b) External error control 


Figure 12.2 Internal and External Error Control 
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decrypts the incoming block and treats the results as a message with an appended 
FCS. B applies the same function F to attempt to reproduce the FCS. If the calcu- 
lated FCS is equal to the incoming FCS, then the message is considered authentic. It 
is unlikely that any random sequence of bits would exhibit the desired relationship. 

Note that the order in which the FCS and encryption functions are performed 
is critical. The sequence illustrated in Figure 12.2a is referred to in [DIFF79] 
as internal error control, which the authors contrast with external error control 
(Figure 12.2b). With internal error control, authentication is provided because an 
opponent would have difficulty generating ciphertext that, when decrypted, would 
have valid error control bits. If instead the FCS is the outer code, an opponent can 
construct messages with valid error-control codes. Although the opponent cannot 
know what the decrypted plaintext will be, he or she can still hope to create confu- 
sion and disrupt operations. 

An error-control code is just one example; in fact, any sort of structuring 
added to the transmitted message serves to strengthen the authentication capability. 
Such structure is provided by the use of a communications architecture consisting of 
layered protocols. As an example, consider the structure of messages transmitted 
using the TCP/IP protocol architecture. Figure 12.3 shows the format of a TCP seg- 
ment, illustrating the TCP header. Now suppose that each pair of hosts shared a 
unique secret key, so that all exchanges between a pair of hosts used the same key, 
regardless of application. Then we could simply encrypt all of the datagram except 
the IP header. Again, if an opponent substituted some arbitrary bit pattern for the 
encrypted TCP segment, the resulting plaintext would not include a meaningful 
header. In this case, the header includes not only a checksum (which covers the 
header) but also other useful information, such as the sequence number. Because 
successive TCP segments on a given connection are numbered sequentially, encryp- 
tion assures that an opponent does not delay, misorder, or delete any segments. 


PusLic-Key Encryption The straightforward use of public-key encryption 
(Figure 12.1b) provides confidentiality but not authentication. The source (A) uses 
the public key PU, of the destination (B) to encrypt M. Because only B has the 


20 octets 


Data 
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corresponding private key PR,, only B can decrypt the message. This scheme 
provides no authentication, because any opponent could also use B’s public key to 
encrypt a message and claim to be A. 

To provide authentication, A uses its private key to encrypt the message, and B 
uses A’s public key to decrypt (Figure 12.1c). This provides authentication using the 
same type of reasoning as in the symmetric encryption case: The message must have 
come from A because A is the only party that possesses PR, and therefore the only 
party with the information necessary to construct ciphertext that can be decrypted 
with PU,. Again, the same reasoning as before applies: There must be some internal 
structure to the plaintext so that the receiver can distinguish between well-formed 
plaintext and random bits. 

Assuming there is such structure, then the scheme of Figure 12.1c does provide 
authentication. It also provides what is known as digital signature.! Only A could 
have constructed the ciphertext because only A possesses PR,. Not even B, the 
recipient, could have constructed the ciphertext. Therefore, if B is in possession of 
the ciphertext, B has the means to prove that the message must have come from A. 
In effect, A has “signed” the message by using its private key to encrypt. Note that 
this scheme does not provide confidentiality. Anyone in possession of A’s public key 
can decrypt the ciphertext. 

To provide both confidentiality and authentication, A can encrypt M first 
using its private key, which provides the digital signature, and then using B’s public 
key, which provides confidentiality (Figure 12.1d). The disadvantage of this 
approach is that the public-key algorithm, which is complex, must be exercised four 
times rather than two in each communication. 


Message Authentication Code 


An alternative authentication technique involves the use of a secret key to generate 
a small fixed-size block of data, known as a cryptographic checksum or MAC, that is 
appended to the message. This technique assumes that two communicating parties, 
say A and B, share a common secret key K. When A has a message to send to B, it 
calculates the MAC as a function of the message and the key: 


MAC = MAC(K, M) 
where 
M ~ =input message 
C = MAC function 
K 


= shared secret key 


MAC = message authentication code 


The message plus MAC are transmitted to the intended recipient. The recipient per- 
forms the same calculation on the received message, using the same secret key, to 


'This is not the way in which digital signatures are constructed, as we shall see, but the principle is the 
same. 
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Figure 12.4 Basic Uses of Message Authentication code (MAC) 


generate a new MAC. The received MAC is compared to the calculated MAC 
(Figure 12.4a). If we assume that only the receiver and the sender know the identity 
of the secret key, and if the received MAC matches the calculated MAC, then 


1. The receiver is assured that the message has not been altered. If an attacker 
alters the message but does not alter the MAC, then the receiver’s calculation 
of the MAC will differ from the received MAC. Because the attacker is 
assumed not to know the secret key, the attacker cannot alter the MAC to cor- 
respond to the alterations in the message. 


nN 


. The receiver is assured that the message is from the alleged sender. Because no 


one else knows the secret key, no one else could prepare a message with a proper 
MAC. 


3. If the message includes a sequence number (such as is used with HDLC, X.25, 
and TCP), then the receiver can be assured of the proper sequence because an 
attacker cannot successfully alter the sequence number. 


A MAC function is similar to encryption. One difference is that the MAC 
algorithm need not be reversible, as it must be for decryption. In general, the MAC 
function is a many-to-one function. The domain of the function consists of messages 
of some arbitrary length, whereas the range consists of all possible MACs and all 
possible keys. If an n-bit MAC is used, then there are 2” possible MACs, whereas 
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there are N possible messages with N >> 2”. Furthermore, with a k-bit key, there 
are 2* possible keys. 

For example, suppose that we are using 100-bit messages and a 10-bit MAC. 
Then, there are a total of 2!°” different messages but only 2'° different MACs. So, on 
average, each MAC value is generated by a total of 2'°°/2'° = 2” different mes- 
sages. If a 5-bit key is used, then there are 2° = 32 different mappings from the set of 
messages to the set of MAC values. 

It turns out that, because of the mathematical properties of the authentication 
function, it is less vulnerable to being broken than encryption. 

The process depicted in Figure 12.4a provides authentication but not confiden- 
tiality, because the message as a whole is transmitted in the clear. Confidentiality can 
be provided by performing message encryption either after (Figure 12.4b) or before 
(Figure 12.4c) the MAC algorithm. In both these cases, two separate keys are needed, 
each of which is shared by the sender and the receiver. In the first case, the MAC is 
calculated with the message as input and is then concatenated to the message. The 
entire block is then encrypted. In the second case, the message is encrypted first. 
Then the MAC is calculated using the resulting ciphertext and is concatenated to the 
ciphertext to form the transmitted block. Typically, it is preferable to tie the authenti- 
cation directly to the plaintext, so the method of Figure 12.4b is used. 

Because symmetric encryption will provide authentication and because it is 
widely used with readily available products, why not simply use this instead of a sep- 
arate message authentication code? [DAVI89] suggests three situations in which a 
message authentication code is used. 


1. There are a number of applications in which the same message is broadcast to 
a number of destinations. Examples are notification to users that the network 
is now unavailable or an alarm signal in a military control center. It is cheaper 
and more reliable to have only one destination responsible for monitoring 
authenticity. Thus, the message must be broadcast in plaintext with an associ- 
ated message authentication code. The responsible system has the secret key 
and performs authentication. If a violation occurs, the other destination 
systems are alerted by a general alarm. 


N 


. Another possible scenario is an exchange in which one side has a heavy load 
and cannot afford the time to decrypt all incoming messages. Authentication 
is carried out on a selective basis, messages being chosen at random for 
checking. 


3. Authentication of a computer program in plaintext is an attractive service. The 
computer program can be executed without having to decrypt it every time, 
which would be wasteful of processor resources. However, if a message authenti- 
cation code were attached to the program, it could be checked whenever assur- 
ance was required of the integrity of the program. 


Three other rationales may be added. 


4. For some applications, it may not be of concern to keep messages secret, but it is 
important to authenticate messages. An example is the Simple Network 
Management Protocol Version 3 (SNMPv3), which separates the functions of 
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confidentiality and authentication. For this application, it is usually important for 
a managed system to authenticate incoming SNMP messages, particularly if the 
message contains a command to change parameters at the managed system. On 
the other hand, it may not be necessary to conceal the SNMP traffic. 


on 


. Separation of authentication and confidentiality functions affords architectural 
flexibility. For example, it may be desired to perform authentication at the appli- 
cation level but to provide confidentiality at a lower level, such as the transport 
layer. 


6. A user may wish to prolong the period of protection beyond the time of recep- 
tion and yet allow processing of message contents. With message encryption, 
the protection is lost when the message is decrypted, so the message is pro- 
tected against fraudulent modifications only in transit but not within the target 
system. 


Finally, note that the MAC does not provide a digital signature, because both 
sender and receiver share the same key. 


12.3 REQUIREMENTS FOR MESSAGE AUTHENTICATION CODES 


A MAC, also known as a cryptographic checksum, is generated by a function C of 
the form 


T = MAC(K, M) 


where M is a variable-length message, K is a secret key shared only by sender and 
receiver, and MAC(K, M) is the fixed-length authenticator, sometimes called a tag. 
The tag is appended to the message at the source at a time when the message is 
assumed or known to be correct. The receiver authenticates that message by recom- 
puting the tag. 

When an entire message is encrypted for confidentiality, using either sym- 
metric or asymmetric encryption, the security of the scheme generally depends on 
the bit length of the key. Barring some weakness in the algorithm, the opponent 
must resort to a brute-force attack using all possible keys. On average, such an 
attack will require 2“~) attempts for a k-bit key. In particular, for a ciphertext- 
only attack, the opponent, given ciphertext C, performs P; = D(K;, C) for all pos- 
sible key values K; until a P; is produced that matches the form of acceptable 
plaintext. 

In the case of a MAC, the considerations are entirely different. In general, the 
MAC function is a many-to-one function, due to the many-to-one nature of the 
function. Using brute-force methods, how would an opponent attempt to discover a 
key? If confidentiality is not employed, the opponent has access to plaintext mes- 
sages and their associated MACs. Suppose k > n; that is, suppose that the key size is 
greater than the MAC size. Then, given a known M, and 7), with 
T, = MAC(K, M;), the cryptanalyst can perform T; = MAC(K;, M;) for all possi- 
ble key values k;. At least one key is guaranteed to produce a match of 7; = 7}. 
Note that a total of 2* tags will be produced, but there are only 2” < 2* different tag 
values. Thus, a number of keys will produce the correct tag and the opponent has no 
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way of knowing which is the correct key. On average, a total of 2/2" = 2“~") keys 
will produce a match. Thus, the opponent must iterate the attack. 


¢ Round 1 


Given: M,,T, = MAC(K, M;) 
Compute 7; = MAC(K;, M,) _ for all 2 keys 
Number of matches ~ 2“~”) 


e Round 2 


Given: M3, T, = MAC(K, M2) 
Compute T; = MAC(K;, M2) _ for the 2*~” keys resulting from Round 1 
Number of matches ~ 2*~2*”) 


And so on. On average, o rounds will be needed if k = a X n. For example, if an 
80-bit key is used and the tab is 32 bits, then the first round will produce about 2*° 
possible keys. The second round will narrow the possible keys to about 2'° possibili- 
ties. The third round should produce only a single key, which must be the one used 
by the sender. 

If the key length is less than or equal to the tag length, then it is likely that a 
first round will produce a single match. It is possible that more than one key will 
produce such a match, in which case the opponent would need to perform the same 
test on a new (message, tag) pair. 

Thus, a brute-force attempt to discover the authentication key is no less effort 
and may be more effort than that required to discover a decryption key of the same 
length. However, other attacks that do not require the discovery of the key are 
possible. 

Consider the following MAC algorithm. Let M = (X,|I X9ll ... Il X,,) be a 
message that is treated as a concatenation of 64-bit blocks X;. Then define 


A(M) = XO X20 c D Xm 
MAC(K, M) = E(K, A(M)) 


where @) is the exclusive-OR (XOR) operation and the encryption algorithm is 
DES in electronic codebook mode. Thus, the key length is 56 bits, and the tag length 
is 64 bits. If an opponent observes {M || MAC(K, M)}, a brute-force attempt to 
determine K will require at least 2°° encryptions. But the opponent can attack the 
system by replacing X, through X,,,_, with any desired values Y, through Y,,,; and 
replacing X,,, with Y,,, where Y,,, is calculated as 


Ym = Yr ¥o@ ** @® Yn-1 @ A(M) 


The opponent can now concatenate the new message, which consists of Y; 
through Y,,,, using the original tag to form a message that will be accepted as authen- 
tic by the receiver. With this tactic, any message of length 64 < (m — 1) bits can be 
fraudulently inserted. 

Thus, in assessing the security of a MAC function, we need to consider the 
types of attacks that may be mounted against it. With that in mind, let us state the 
requirements for the function. Assume that an opponent knows the MAC function 
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but does not know K. Then the MAC function should satisfy the following 
requirements. 


1. If an opponent observes M and MAC(K, M), it should be computationally 
infeasible for the opponent to construct a message M' such that 
MAC(K, M') = MAC(K, M) 
. MAC(K, M) should be uniformly distributed in the sense that for randomly cho- 
sen messages, M and M', the probability that MAC(K, M) = MAC(K, M’) is 
2~", where n is the number of bits in the tag. 


nN 


3. Let M’ be equal to some known transformation on M. That is, M’ = f(M). For 
example, f may involve inverting one or more specific bits. In that case, 


Pr [MAC(K, M) = MAC(K, M’)] = 27 


The first requirement speaks to the earlier example, in which an opponent is 
able to construct a new message to match a given tag, even though the opponent 
does not know and does not learn the key. The second requirement deals with the 
need to thwart a brute-force attack based on chosen plaintext. That is, if we assume 
that the opponent does not know K but does have access to the MAC function and 
can present messages for MAC generation, then the opponent could try various 
messages until finding one that matches a given tag. If the MAC function exhibits 
uniform distribution, then a brute-force method would require, on average, 2'"~!) 
attempts before finding a message that fits a given tag. 

The final requirement dictates that the authentication algorithm should not be 
weaker with respect to certain parts or bits of the message than others. If this were 
not the case, then an opponent who had M and MAC(K, M) could attempt varia- 
tions on M at the known “weak spots” with a likelihood of early success at produc- 
ing a new message that matched the old tags. 


12.4 SECURITY OF MACS 


Just as with encryption algorithms and hash functions, we can group attacks on 
MACs into two categories: brute-force attacks and cryptanalysis. 


Brute-Force Attacks 


A brute-force attack on a MAC is a more difficult undertaking than a brute-force 
attack on a hash function because it requires known message-tag pairs. Let us see 
why this is so. To attack a hash code, we can proceed in the following way. Given a 
fixed message x with n-bit hash code h = H(x), a brute-force method of finding a 
collision is to pick a random bit string y and check if H(y) = H(x). The attacker can 
do this repeatedly off line. Whether an off-line attack can be used on a MAC algo- 
rithm depends on the relative size of the key and the tag. 

To proceed, we need to state the desired security property of a MAC algo- 
rithm, which can be expressed as follows. 


e Computation resistance: Given one or more text-MAC pairs [x,, MAC(K, x;)], 
it is computationally infeasible to compute any  text-MAC pair 
[x, MAC(K, x)] for any new input x # x;. 
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In other words, the attacker would like to come up with the valid MAC code for a 
given message x. There are two lines of attack possible: attack the key space and 
attack the MAC value. We examine each of these in turn. 

If an attacker can determine the MAC key, then it is possible to generate a 
valid MAC value for any input x. Suppose the key size is k bits and that the attacker 
has one known text-tag pair. Then the attacker can compute the n-bit tag on the 
known text for all possible keys. At least one key is guaranteed to produce the cor- 
rect tag, namely, the valid key that was initially used to produce the known text-tag 
pair. This phase of the attack takes a level of effort proportional to 2* (that is, one 
operation for each of the 2‘ possible key values). However, as was described earlier, 
because the MAC is a many-to-one mapping, there may be other keys that produce 
the correct value. Thus, if more than one key is found to produce the correct value, 
additional text-tag pairs must be tested. It can be shown that the level of effort 
drops off rapidly with each additional text-MAC pair and that the overall level of 
effort is roughly 2° [MENE97]. 

An attacker can also work on the tag without attempting to recover the 
key. Here, the objective is to generate a valid tag for a given message or to find a 
message that matches a given tag. In either case, the level of effort is comparable 
to that for attacking the one-way or weak collision-resistant property of a hash 
code, or 2”. In the case of the MAC, the attack cannot be conducted off line 
without further input; the attacker will require chosen text-tag pairs or knowl- 
edge of the key. 

To summarize, the level of effort for brute-force attack on a MAC algorithm 
can be expressed as min(2*, 2”). The assessment of strength is similar to that for 
symmetric encryption algorithms. It would appear reasonable to require that the 
key length and tag length satisfy a relationship such as min(k, n) = N, where N is 
perhaps in the range of 128 bits. 


Cryptanalysis 


As with encryption algorithms and hash functions, cryptanalytic attacks on MAC 
algorithms seek to exploit some property of the algorithm to perform some attack 
other than an exhaustive search. The way to measure the resistance of a MAC 
algorithm to cryptanalysis is to compare its strength to the effort required for a 
brute-force attack. That is, an ideal MAC algorithm will require a cryptanalytic 
effort greater than or equal to the brute-force effort. 

There is much more variety in the structure of MACs than in hash functions, so 
it is difficult to generalize about the cryptanalysis of MACs. Furthermore, far less 
work has been done on developing such attacks. A useful survey of some methods 
for specific MACs is [PREN96]. 


12.5 MACs BASED ON HASH FUNCTIONS: HMAC 


Later in this chapter, we look at examples of a MAC based on the use of a symmet- 
ric block cipher. This has traditionally been the most common approach to 
constructing a MAC. In recent years, there has been increased interest in developing 
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a MAC derived from a cryptographic hash function. The motivations for this 
interest are 


1. Cryptographic hash functions such as MD5 and SHA generally execute faster 
in software than symmetric block ciphers such as DES. 


2. Library code for cryptographic hash functions is widely available. 


With the development of AES and the more widespread availability of code 
for encryption algorithms, these considerations are less significant, but hash-based 
MACs continue to be widely used. 

A hash function such as SHA was not designed for use as a MAC and cannot 
be used directly for that purpose, because it does not rely on a secret key. There have 
been a number of proposals for the incorporation of a secret key into an existing 
hash algorithm. The approach that has received the most support is HMAC 
[BELL96a, BELL96b]. HMAC has been issued as RFC 2104, has been chosen as the 
mandatory-to-implement MAC for IP security, and is used in other Internet proto- 
cols, such as SSL. HMAC has also been issued as a NIST standard (FIPS 198). 


HMAC Design Objectives 
RFC 2104 lists the following design objectives for HMAC. 


e To use, without modifications, available hash functions. In particular, to use 
hash functions that perform well in software and for which code is freely and 
widely available. 


e To allow for easy replaceability of the embedded hash function in case faster 
or more secure hash functions are found or required. 


e To preserve the original performance of the hash function without incurring a 
significant degradation. 


e To use and handle keys in a simple way. 


e To have a well understood cryptographic analysis of the strength of the 
authentication mechanism based on reasonable assumptions about the 
embedded hash function. 


The first two objectives are important to the acceptability of HMAC. HMAC 
treats the hash function as a “black box.” This has two benefits. First, an existing 
implementation of a hash function can be used as a module in implementing 
HMAC. In this way, the bulk of the HMAC code is prepackaged and ready to use 
without modification. Second, if it is ever desired to replace a given hash function in 
an HMAC implementation, all that is required is to remove the existing hash func- 
tion module and drop in the new module. This could be done if a faster hash func- 
tion were desired. More important, if the security of the embedded hash function 
were compromised, the security of HMAC could be retained simply by replacing 
the embedded hash function with a more secure one (e.g., replacing SHA-2 with 
SHA-3). 

The last design objective in the preceding list is, in fact, the main advantage of 
HMAC over other proposed hash-based schemes. HMAC can be proven secure 
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provided that the embedded hash function has some reasonable cryptographic 
strengths. We return to this point later in this section, but first we examine the struc- 
ture of HMAC. 


HMAC Algorithm 
Figure 12.5 illustrates the overall operation of HMAC. Define the following terms. 
H = embedded hash function (e.g., MD5, SHA-1, RIPEMD-160) 


IV = initial value input to hash function 


M = message input to HMAC (including the padding specified in the embed- 
ded hash function) 


= ith block of M,0 =i s(L-1) 
= number of blocks in M 


= number of bits in a block 


length of hash code produced by embedded hash function 


ATTN 


= secret key; recommended length is = n; if key length is greater than b, 
the key is input to the hash function to produce an -bit key 


+ A 
K ipad 
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Figure 12.5 HMAC Structure 
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K* = K padded with zeros on the left so that the result is b bits in length 
ipad = 00110110 (36 in hexadecimal) repeated b/8 times 
opad = 01011100 (SC in hexadecimal) repeated b/8 times 


Then HMAC can be expressed as 
HMAC(K, M) = H[(K* @ opad) || H[(K* @ ipad) || MJ] 


We can describe the algorithm as follows. 


—_ 


. Append zeros to the left end of K to create a b-bit string K* (e.g., if K is of 
length 160 bits and b = 512, then K will be appended with 44 zeroes). 


2. XOR (bitwise exclusive-OR) K* with ipad to produce the b-bit block S;. 
3. Append M to Si. 

4. Apply H to the stream generated in step 3. 

5. XOR K* with opad to produce the b-bit block S,. 

6. Append the hash result from step 4 to S,. 

7. Apply H to the stream generated in step 6 and output the result. 


Note that the XOR with ipad results in flipping one-half of the bits of K. 
Similarly, the XOR with opad results in flipping one-half of the bits of K, using a dif- 
ferent set of bits. In effect, by passing S; and S, through the compression function of 
the hash algorithm, we have pseudorandomly generated two keys from K. 

HMAC should execute in approximately the same time as the embedded hash 
function for long messages. HMAC adds three executions of the hash compression 
function (for $;, S,,and the block produced from the inner hash). 

A more efficient implementation is possible, as shown in Figure 12.6. Two 
quantities are precomputed: 


f(IV, (K* @ ipad)) 
f(IV, (K * @ opad)) 


where f(cv, block) is the compression function for the hash function, which takes as 
arguments a chaining variable of n bits and a block of b bits and produces a chaining 
variable of 1 bits. These quantities only need to be computed initially and every time 
the key changes. In effect, the precomputed quantities substitute for the initial value 
(JV) in the hash function. With this implementation, only one additional instance of 
the compression function is added to the processing normally produced by the hash 
function. This more efficient implementation is especially worthwhile if most of the 
messages for which a MAC is computed are short. 


Security of HMAC 


The security of any MAC function based on an embedded hash function depends 
in some way on the cryptographic strength of the underlying hash function. The 
appeal of HMAC is that its designers have been able to prove an exact relationship 
between the strength of the embedded hash function and the strength of HMAC. 
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Figure 12.6 Efficient Implementation of HMAC 


The security of a MAC function is generally expressed in terms of the proba- 
bility of successful forgery with a given amount of time spent by the forger and a 
given number of message-tag pairs created with the same key. In essence, it is 
proved in [BELL96a] that for a given level of effort (time, message—tag pairs) on 
messages generated by a legitimate user and seen by the attacker, the probability of 
successful attack on HMAC is equivalent to one of the following attacks on the 
embedded hash function. 


1. The attacker is able to compute an output of the compression function even 
with an /V that is random, secret, and unknown to the attacker. 


2. The attacker finds collisions in the hash function even when the JV is random 
and secret. 


In the first attack, we can view the compression function as equivalent to the 
hash function applied to a message consisting of a single b-bit block. For this attack, 
the JV of the hash function is replaced by a secret, random value of n bits. An attack 
on this hash function requires either a brute-force attack on the key, which is a level 
of effort on the order of 2”, or a birthday attack, which is a special case of the second 
attack, discussed next. 
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In the second attack, the attacker is looking for two messages M and M’ that 
produce the same hash: H(M) = H(M’). This is the birthday attack discussed in 
Chapter 11. We have shown that this requires a level of effort of 2”” for a hash 
length of n. On this basis, the security of MDS is called into question, because a level 
of effort of 2“ looks feasible with today’s technology. Does this mean that a 128-bit 
hash function such as MDS is unsuitable for HMAC? The answer is no, because of 
the following argument. To attack MDS, the attacker can choose any set of messages 
and work on these off line on a dedicated computing facility to find a collision. 
Because the attacker knows the hash algorithm and the default /V, the attacker can 
generate the hash code for each of the messages that the attacker generates. 
However, when attacking HMAC, the attacker cannot generate message/code pairs 
off line because the attacker does not know K. Therefore, the attacker must observe 
a sequence of messages generated by HMAC under the same key and perform the 
attack on these known messages. For a hash code length of 128 bits, this requires 2™ 
observed blocks (2” bits) generated using the same key. On a 1-Gbps link, one 
would need to observe a continuous stream of messages with no change in key for 
about 150,000 years in order to succeed. Thus, if speed is a concern, it is fully accept- 
able to use MD5 rather than SHA-1 as the embedded hash function for HMAC. 


12.6 MACs BASED ON BLOCK CIPHERS: DAA AND CMAC 


In this section, we look at two MACs that are based on the use of a block cipher 
mode of operation. We begin with an older algorithm, the Data Authentication 
Algorithm (DAA), which is now obsolete. Then we examine CMAC, which is 
designed to overcome the deficiencies of DAA. 


Data Authentication Algorithm 


The Data Authentication Algorithm (DAA), based on DES, has been one of the 
most widely used MACs for a number of years. The algorithm is both a FIPS publi- 
cation (FIPS PUB 113) and an ANSI standard (X9.17). However, as we discuss sub- 
sequently, security weaknesses in this algorithm have been discovered, and it is 
being replaced by newer and stronger algorithms. 

The algorithm can be defined as using the cipher block chaining (CBC) mode of 
operation of DES (Figure 6.4) with an initialization vector of zero. The data (e.g., mes- 
sage, record, file, or program) to be authenticated are grouped into contiguous 64-bit 
blocks: Di, D2, ..., Dy. If necessary, the final block is padded on the right with zeroes 
to form a full 64-bit block. Using the DES encryption algorithm E and a secret key K, 
a data authentication code (DAC) is calculated as follows (Figure 12.7). 


O, = E(K,D) 
O, = E(K,[D2@ O;)) 
Oz; = E(K, [D3 @ O}]) 


On = E(K, [Dy © On-1]) 
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Time = 1 


Dd 
(64 bits) 


K 


(56 bits) SDeny Dl 


0; 
(64 bits) 
SO 
DAC 
(16 to 64 bits) 


Figure 12.7. Data Authentication Algorithm (FIPS PUB 113) 


The DAC consists of either the entire block Oy or the leftmost M bits of the 
block, with 16 = M S 64. 


Cipher-Based Message Authentication Code (CMAC) 


As was mentioned, DAA has been widely adopted in government and industry. 
[BELL00] demonstrated that this MAC is secure under a reasonable set of security 
criteria, with the following restriction. Only messages of one fixed length of mn bits 
are processed, where nis the cipher block size and m is a fixed positive integer. As a 
simple example, notice that given the CBC MAC of a one-block message X, say 
T = MAC(K, X), the adversary immediately knows the CBC MAC for the two- 
block message X || (X @ T) since this is once again 7. 

Black and Rogaway [BLAC00] demonstrated that this limitation could be 
overcome using three keys: one key of length K to be used at each step of the 
cipher block chaining and two keys of length 1, where k is the key length and n is 
the cipher block length. This proposed construction was refined by Iwata and 
Kurosawa so that the two n-bit keys could be derived from the encryption key, 
rather than being provided separately [[WATO03]. This refinement, adopted by 
NIST, is the Cipher-based Message Authentication Code (CMAC) mode of oper- 
ation for use with AES and triple DES. It is specified in NIST Special Publication 
800-38B. 

First, let us define the operation of CMAC when the message is an integer 
multiple n of the cipher block length b. For AES, b = 128, and for triple DES, 
b = 64. The message is divided into n blocks (M,, Mo, ..., M,,). The algorithm 
makes use of a k-bit encryption key K and an n-bit constant, K,. For AES, the key 
size k is 128, 192, or 256 bits; for triple DES, the key size is 112 or 168 bits. CMAC is 
calculated as follows (Figure 12.8). 
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M, M, e e e M, 


K—>|__ Encrypt K —|__ Encrypt 


MSB(Zlen) /}-—> T 


(b) Message length is not integer multiple of block size 
Figure 12.8 Cipher-Based Message Authentication Code (CMAC) 


CG, = EK,M) 
Cy = E(K,[M,@ Ci) 
C3; = E(k, [M3 @ G]) 
Ch — E(K, [M,, ® Cy-1 ® K,]) 
i = MSB Tlen(Cn) 
where 
T = message authetication code, also referred to as the tag 
Tlen = bit length of T 
MSB,(X) = the s leftmost bits of the bit string X 


If the message is not an integer multiple of the cipher block length, then the 
final block is padded to the right (least significant bits) with a 1 and as many Os as 
necessary so that the final block is also of length b. The CMAC operation then pro- 
ceeds as before, except that a different n-bit key K> is used instead of Kj. 
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The two n-bit keys are derived from the k-bit encryption key as follows. 


L = E(K, 0") 
ky =Lex 
Ko = Leg = (Lex)*x 


where multiplication (° ) is done in the finite field GF(2”) and x and x’ are first- and 
second-order polynomials that are elements of GF(2”). Thus, the binary representa- 
tion of x consists of n — 2 zeros followed by 10; the binary representation of x? con- 
sists of n — 3 zeros followed by 100. The finite field is defined with respect to an 
irreducible polynomial that is lexicographically first among all such polynomials 
with the minimum possible number of nonzero terms. For the two approved block 
sizes, the polynomials are x + x4 + 8 +x 4+ landx8+4+x74+ 27+ x41. 

To generate K, and K5, the block cipher is applied to the block that consists 
entirely of 0 bits. The first subkey is derived from the resulting ciphertext by a left 
shift of one bit and, conditionally, by XORing a constant that depends on the block 
size. The second subkey is derived in the same manner from the first subkey. This 
property of finite fields of the form GF(2”) was explained in the discussion of 
MixColumns in Chapter 5. 


12.7 AUTHENTICATED ENCRYPTION: CCM AND GCM 


Authenticated encryption (AE) is a term used to describe encryption systems that 
simultaneously protect confidentiality and authenticity (integrity) of communica- 
tions. Many applications and protocols require both forms of security, but until 
recently the two services have been designed separately. 

[BLACO0S] discussed four common approaches to providing both confidential- 
ity and encryption for a message M. 


e HtE: Hash-then-encrypt. First compute the cryptographic hash function over 
Mash = H(M). Then encrypt the message plus hash function: E(K, (MIlA)). 


e MtE: MAC-then-encrypt. Use two keys. First authenticate the plaintext by 
computing the MAC value as T = MAC(K,, M). Then encrypt the message 
plus tag: E(K>, (M || T). This approach is taken by the SSL/TLS protocols 
(Chapter 16). 


e EtM: Encrypt-then-MAC. Use two keys. First encrypt the message to yield the 
ciphertext C= E(K,,M). Then authenticate the ciphertext with 
T = MAC(K,, C) to yield the pair (C, 7). This approach is used in the IPsec 
protocol (Chapter 19). 

e E&M: Encrypt-and-MAC. Use two keys. Encrypt the message to yield the 
ciphertext C = E(K>, M). Authenticate the plaintext with T = MAC(K,, M) 
to yield the pair (C, T). These operations can be performed in either order. 
This approach is used by the SSH protocol (Chapter 16). 


Both decryption and verification are straightforward for each approach. For 
HtE, MtE, and E&M, decrypt first, then verify. For EtM, verify first, then decrypt. 
There are security vulnerabilities with all of these approaches. The HtE approach is 
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used in the Wired Equivalent Privacy (WEP) protocol to protect WiFi networks. This 
approach had fundamental weaknesses and led to the replacement of the WEP proto- 
col. [BLAC05] and [BELL00] point out that there security concerns in each of the 
three encryption/MAC approaches listed above. Nevertheless, with proper design, any 
of these approaches can provide a high level of security. This is the goal of the two 
approaches discussed in this section, both of which have been standardized by NIST. 


Counter with Cipher Block Chaining-Message 
Authentication Code 


The CCM mode of operation was standardized by NIST specifically to support 
the security requirements of IEEE 802.11 WiFi wireless local area networks 
(Chapter 17), but can be used in any networking application requiring authenticated 
encryption. CCM is a variation of the encrypt-and-MAC approach to authenticated 
encryption. It is defined in NIST SP 800-38C. 

The key algorithmic ingredients of CCM are the AES encryption algorithm 
(Chapter 5), the CTR mode of operation (Chapter 6), and the CMAC authentica- 
tion algorithm (Section 12.6). A single key K is used for both encryption and MAC 
algorithms. The input to the CCM encryption process consists of three elements. 


1. Data that will be both authenticated and encrypted. This is the plaintext 
message P of data block. 


nN 


. Associated data A that will be authenticated but not encrypted. An example is 
a protocol header that must be transmitted in the clear for proper protocol 
operation but which needs to be authenticated. 


3. A nonce N that is assigned to the payload and the associated data. This is a 
unique value that is different for every instance during the lifetime of a proto- 
col association and is intended to prevent replay attacks and certain other 
types of attacks. 


Figure 12.9 illustrates the operation of CCM. For authentication, the input 
includes the nonce, the associated data, and the plaintext. This input is formatted as 
a sequence of blocks By through B,. The first block contains the nonce plus some 
formatting bits that indicate the lengths of the N, A, and P elements. This is fol- 
lowed by zero or more blocks that contain A, followed by zero of more blocks that 
contain P. The resulting sequence of blocks serves as input to the CMAC algorithm, 
which produces a MAC value with length Tlen, which is less than or equal to the 
block length (Figure 12.9a). 

For encryption, a sequence of counters is generated that must be independent 
of the nonce. The authentication tag is encrypted in CTR mode using the single 
counter Ctrp. The Tlen most significant bits of the output are XORed with the tag to 
produce an encrypted tag. The remaining counters are used for the CTR mode 
encryption of the plaintext (Figure 6.7). The encrypted plaintext is concatenated 
with the encrypted tag to form the ciphertext output (Figure 12.9b). 

SP 800-38C defines the authentication/encryption process as follows. 


1. Apply the formatting function to (N,A,P) to produce the blocks 
Bo, By,..., By 


2. Set Yy = E(K, Bp). 
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Ctr, Ctr, ... Tin 


Plaintext 


Tag 


(a) Authentication 


MSB(Tlen) 


—————— ee  .)~C~CS 


(b) Encryption 


Figure 12.9 Counter with Cipher Block Chaining-Message Authentication Code (CCM) 


For i = 1 tor,do Y; = E(K, (B;® Y;-})). 
Set T = MSB 7, Y,). 


Apply the counter generation function to generate the counter blocks 
Ciro, Ctr), ..., Ct, where m = | Plen/128 |. 


. Forj = 0 to m,do S; = E(K, Ctr). 


7. Set S = S,Il Syll--- ll Sip. 


oO 


. Return C = (P ® MSBpx,(S)) | (T @® MSB ren(So))- 
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For decryption and verification, the recipient requires the following input: the 
ciphertext C, the nonce N, the associated data A, the key K, and the initial counter 
Ctry. The steps are as follows. 


1. If Clen < Tlen, then return INVALID. 


2. Apply the counter generation function_to generate the counter blocks 
Ciro, Ctr, ...4 Ct, where m = | Clen/128 |. 


3. For j = 0tom,do S, = ECK, Ci). 
4. Set S = S,Il Soll... 11S), 
5. Set P = MSBefen—ten(C) 8 MSBjen—Ten(S)- 
6. Set T = LSB ren(C) ® MSB 7en(So). 
7. Apply the formatting function to (N,A,P) to produce the blocks 
Bo, By, ..., B,. 
8. Set Yo = E(K, Bo). 
9. Fori = 1 tor,do Y; = E(K, (B; © Y;_,)). 
10. If T # MSB 7, (Y,), then return INVALID, else return P. 


CCM is a relatively complex algorithm. Note that it requires two complete 
passes through the plaintext, once to generate the MAC value, and once for encryp- 
tion. Further, the details of the specification require a tradeoff between the length of 
the nonce and the length of the tag, which is an unnecessary restriction. Also note that 
the encryption key is used twice with the CTR encryption mode: once to generate the 
tag and once to encrypt the plaintext plus tag. Whether these complexities add to the 
security of the algorithm is not clear. In any case, two analyses of the algorithm 
([JONS02] and [ROGA03]) conclude that CCM provides a high level of security. 


Galois/Counter Mode 


The GCM mode of operation, standardized by NIST in NIST SP 800-38D, is 
designed to be parallelizable so that it can provide high throughput with low cost 
and low latency. In essence, the message is encrypted in variant of CTR mode. The 
resulting ciphertext is multiplied with key material and message length information 
over GF(2'*8) to generate the authenticator tag. The standard also specifies a mode 
of operation that supplies the MAC only, known as GMAC. 

The GCM mode makes use of two functions: GHASH, which is a keyed hash 
function, and GCTR, which is essentially the CTR mode with the counters deter- 
mined by a simple increment by one operation. 

GHASH,(X) takes a input the hash key H and a bit string X such that 
len(X) = 128m bits for some positive integer m and produces a 128-bit MAC value. 
The function may be specified as follows (Figure 12.10a). 


1. Let X41, Xo, ..., Xin—1, Xm denote the unique sequence of blocks such that 
X = X1I| XII... | X_—1 ll Xin. 

. Let Yo be a block of 128 zeros, designated as 0!”*. 

. Fori=1,...,m, let Y; = (Y;-; ® X;)° H, where * designates multiplication 
in GF(2'8). 

4. Return Y,,,. 


ow MN 
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i) 


(a) GHASH)(X} II_X3 Il. Xin) = Yn 


(b) GCTR(UICB, X; lI Xz ll... 1X4) = Yq 


Figure 12.10 GCM Authentication and Encryption Functions 


The GHASH,;,(X) function can be expressed as 
(X1° H") @ (Xp A") © +++ © (Xn-1° H’) © (Xm * A) 


This formulation has desirable performance implications. If the same hash key 


is to be used to authenticate multiple messages, then the values H?, H’,... can be 
precalculated one time for use with each message to be authenticated. Then, the 
blocks of the data to be authenticated (X,, Xo, ..., X,,) can be processed in parallel, 
because the computations are independent of one another. 


GCTR,(UCB, X) takes a input a secret key K and a bit string X arbitrary 


length and returns a ciphertext Y of bit length len(X). The function may be specified 
as follows (Figure 12.10b). 


1. If X is the empty string, then return the empty string as Y. 


2. Letn = | (len(X)/ 128) | . That is, n is the smallest integer greater than or equal 
to len(X)/128. 
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3. Let X), X>, ..., X,-1, X, denote the unique sequence of bit strings such that 


X= XM Allin tly WA 
X1, X>, ..., X,-1 are complete 128-bit blocks. 
4. Let CB, = ICB. 


. For, i = 2 ton let CB; = inc3(CB;_,;), where the inc3($) function incre- 
ments the rightmost 32 bits of S by 1 mod 2°, and the remaining bits are 
unchanged. 


6. Fori= 1ton — 1,do Y; = X;@ E(K, CB)). 
7. Let Y; = Xn ® MSBienx(E(K, CB,)). 

8. Let X = X, ll Xyll---_X,-1Il ¥, 

9. Return Y. 


Nn 


Note that the counter values can be quickly generated and that the encryption 
operations can be performed in parallel. 

We can now define the overall authenticated encryption function (Figure 12.11). 
The input consists of a secret key K, an initialization vector JV, a plaintext P, and 


Plaintext 


0 
=o 
H 


Figure 12.11 Galois Counter— Message Authentication Code (GCM) 


12.8 / PEUDORANDOM NUMBER GENERATION USING HASH FUNCTIONS 389 


additional authenticated data A. The notation [x], means the s-bit binary representa- 
tion of the nonnegative integer x. The steps are as follows. 

1. Let H = E(K,0™). 

2. Define a block, Jo, as 

Iflen(IV) = 96, then let Jy = IV || 07" 1. 

Iflen (IV) # 96,then let s = 128 [len(IV)/128| — len(IV), and let 

Jo = GHASH,IV || 0°* Il [len(1V)]o4). 
. Let C = GCTRx(ines2(Jo), P). 
. Let u = 128 |len(C)/128] — len(C) and let v = 128 [len(A)/128 | —len(A). 
. Define a block, S, as 

S = GHASH,,(A 110" Il C11 0" Il [len(A)]eq!l Len(C)]64) 
6. Let T= MSB,GCTRx(Jo, S)), where tis the supported tag length. 
7. Return (C, T). 


nn & WwW 


In step 1, the hash key is generated by encrypting a block of all zeros with the 
secret key K. In step 2, the pre-counter block (Jp) is generated from the JV. In par- 
ticular, when the length of the JV is 96 bits, then the padding string 0*'|| 1 is 
appended to the JV to form the pre-counter block. Otherwise, the IV is padded 
with the minimum number of 0 bits, possibly none, so that the length of the result- 
ing string is a multiple of 128 bits (the block size); this string in turn is appended 
with 64 additional 0 bits, followed by the 64-bit representation of the length of the 
IV, and the GHASH function is applied to the resulting string to form the pre- 
counter block. 

Thus, GCM is based on the CTR mode of operation and adds a MAC that 
authenticates both the message and additional data that requires only authentica- 
tion. The function that computes the hash uses only multiplication in a Galois field. 
This choice was made because the operation of multiplication is easy to perform 
within a Galois field and is easily implemented in hardware [MCGR0OS5]. 

[MCGR04] examines the available block cipher modes of operation and 
shows that a CTR-based authenticated encryption approach is the most efficient 
mode of operation for high-speed packet networks. The paper further demonstrates 
that GCM meets a high level of security requirements. 


12.8 PSEUDORANDOM NUMBER GENERATION USING HASH 
FUNCTIONS AND MACS 


The essential elements of any pseudorandom number generator (PRNG) are a seed 
value and a deterministic algorithm for generating a stream of pseudorandom bits. 
If the algorithm is used as a pseudorandom function (PRF) to produce a required 
value, such as a session key, then the seed should only be known to the user of the 
PREF If the algorithm is used to produce a stream encryption function, then the seed 
has the role of a secret key that must be known to the sender and the receiver. 
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We noted in Chapters 7 and 10 that, because an encryption algorithm pro- 
duces an apparently random output, it can serve as the basis of a (PRNG). Similarly, 
a hash function or MAC produces apparently random output and can be used to 
build a PRNG. Both ISO standard 18031 (Random Bit Generation) and NIST SP 
800-90 (Recommendation for Random Number Generation Using Deterministic 
Random Bit Generators) define an approach for random number generation using a 
cryptographic hash function. SP 800-90 also defines a random number generator 
based on HMAC. We look at these two approaches in turn. 


PRNG Based on Hash Function 


Figure 12.12a shows the basic strategy for a hash-based PRNG specified in SP 800-90 
and ISO 18031. The algorithm takes as input: 
V = seed 


seedlen = bit length of V = k + 64, where k is a desired security level 
expressed in bits 


n= desired number of output bits 


Cryptographic 
hash function 


Pseudorandom 
output 


(a) PRNG using cryptographic hash function 


V 
K HMAC 
Pseudorandom 
output 
(b) PRNG using HMAC 


Figure 12.12 Basic Structure of Hash-Based PRNGs (SP 800-90) 
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The algorithm uses the cryptographic hash function H with an hash value out- 
put of outlen bits. The basic operation of the algorithm is 


m= | n/outlen | 
data = V 
W = the null string 
For i=1tom 

w; = H(data) 

w= W || w; 

data = (data + 1) mod 29¢ed1en 

Return leftmost n bits of W 


Thus, the pseudorandom bit stream is w,II wll... ll w,, with the final block 
truncated if required. 

The SP 800-90 specification also provides for periodically updating V to 
enhance security. The specification also indicates that there are no known or sus- 
pected weaknesses in the hash-based approach for a strong cryptographic hash 
algorithm, such as SHA-2. 


PRNG Based on MAC Function 


Although there are no known or suspected weaknesses in the use of a cryptographic 
hash function for a PRNG in the manner of Figure 12.12a, a higher degree of confi- 
dence can be achieved by using a MAC. Almost invariably, HMAC is used for 
constructing a MAC-based PRNG. This is because HMAC is a widely used stan- 
dardized MAC function and is implemented in many protocols and applications. As 
SP 800-90 points out, the disadvantage of this approach compared to the hash-based 
approach is that the execution time is twice as long, because HMAC involves two 
executions of the underlying hash function for each output block. The advantage of 
the HMAC approach is that it provides a greater degree of confidence in its security, 
compared to a pure hash-based approach. 

For the MAC-based approach, there are two inputs: a key K and a seed V. In 
effect, the combination of K and V form the overall seed for the PRNG specified in 
SP 800-90. Figure 12.12b shows the basic structure of the PRNG mechanism, and the 
leftmost column of Figure 12.13 shows the logic. Note that the key remains the same 
for each block of output, and the data input for each block is equal to the tag output 
of the previous block. The SP 800-90 specification also provides for periodically 
updating K and V to enhance security. 

It is instructive to compare the SP 800-90 recommendation with the use of 
HMAC for a PRNG in some applications, and this is shown in Figure 12.13. For the 
IEEE 802.11i wireless LAN security standard (Chapter 17), the data input consists 
of the seed concatenated with a counter. The counter is incremented for each block 
w; of output. This approach would seem to offer enhanced security compared to the 
SP 800-90 approach. Consider that for SP 800-90, the data input for output block w; 
is just the output w;_; of the previous execution of HMAC. Thus, an opponent who 
is able to observe the pseudorandom output knows both the input and output of 
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m = | n/outlen | m = [n/outlen | m = | n/outlen | 
Wo = V W = the null string A(0O) = V 
W = the null string Fori = ltom W = the null string 
Fori = 1ltom w; = MAC(K, (V Il i)) Fori = 1ltom 
w; = MAC(K, w;_1) W= Wily; A(@i) = MAC(K, A(@-1)) 
W=WIlw; Return leftmost n bits of W w; = MAC(K, (A(i) Il V) 
Return leftmost n bits of W W=WIw; 


Return leftmost n bits of W 


NIST SP 800-90 IEEE 802.11i TLS/WTLS 


Figure 12.13 Three PRNGs Based on HMAC 


HMAC. Even so, with the assumption that HMAC is secure, knowledge of the input 
and output should not be sufficient to recover K and hence not sufficient to predict 
future pseudorandom bits. 

The approach taken by the Transport Layer Security protocol (Chapter 16) 
and the Wireless Transport Layer Security Protocol (Chapter 17) involves invoking 
HMAC twice for each block of output w;. As with IEEE 802.11, this is done in such 
a way that the output does not yield direct information about the input. The double 
use of HMAC doubles the execution burden and would seem to be security overkill. 


12.9 RECOMMENDED READING AND WEB SITE 


[JUENS85] and [JUEN87] provide a good background on message authentication with a focus 
on cryptographic MACs and hash functions. Overviews of HMAC can be found in 
[BELL96a] and [BELL96b]. 


BELL96a_ Bellare, M.; Canetti, R.; and Krawczyk, H. “Keying Hash Functions for 
Message Authentication.” Proceedings, CRYPTO 96, August 1996; published by 
Springer-Verlag. An expanded version is available at http://www-cse.ucsd. 
edu/users/mihir. 


BELL96b_ Bellare, M.; Canetti, R.; and Krawczyk, H. “The HMAC Construction.” 


CryptoBytes, Spring 1996. 

JUEN85 Jueneman, R.; Matyas, S.; and Meyer, C. “Message Authentication.” JEEE 
Communications Magazine, September 1988. 

JUEN87 Jueneman, R. “Electronic Document Authentication.” [EEE Network 
Magazine, April 1987. 
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Recommended Web Site: 


Block cipher modes of operation: NIST page with full information on CMAC, CCM, 
and GCM. 


12.10 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


authenticator 


cryptographic checksum message authentication 


Cipher-Based Message cryptographic hash function message authentication code 
Authentication Code Data Authentication (MAC) 
(CMAC) 
CMAC 


Counter with Cipher Block HMAC 
Chaining-Message 
Authentication Code 


(CCM) 


Algorithm (DAA) 
Galois/Counter Mode (GCM) 


Review Questions 


12.1 What types of attacks are addressed by message authentication? 

12.2 What two levels of functionality comprise a message authentication or digital signa- 
ture mechanism? 

12.3. What are some approaches to producing message authentication? 

12.4 When a combination of symmetric encryption and an error control code is used for 
message authentication, in what order must the two functions be performed? 

12.5 What is a message authentication code? 

12.6 What is the difference between a message authentication code and a one-way hash 
function? 

12.7 In what ways can a hash value be secured so as to provide message authentication? 

12.8 Is it necessary to recover the secret key in order to attack a MAC algorithm? 

12.9 What changes in HMAC are required in order to replace one underlying hash func- 
tion with another? 

Problems 
12.1 If Fis an error-detection function, either internal or external use (Figure 12.2) will 


provide error-detection capability. If any bit of the transmitted message is altered, this 
will be reflected in a mismatch of the received FCS and the calculated FCS, whether 
the FCS function is performed inside or outside the encryption function. Some codes 
also provide an error-correction capability. Depending on the nature of the function, 
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12.6 


12.8 
12.9 


if one or a small number of bits is altered in transit, the error-correction code contains 
sufficient redundant information to determine the errored bit or bits and correct 
them. Clearly, an error-correction code will provide error correction capability when 
used external to the encryption function. Will it also provide this capability if used 
internal to the encryption function? 


The data authentication algorithm, described in Section 12.6, can be defined as using 
the cipher block chaining (CBC) mode of operation of DES with an initialization vec- 
tor of zero (Figure 12.7). Show that the same result can be produced using the cipher 
feedback mode. 

At the beginning of Section 12.6, it was noted that given the CBC MAC of a one- 
block message X, say T = MAC(K, X), the adversary immediately knows the CBC 
MAC for the two-block message X || (X @ T) since this is once again T. Justify this 
statement. 

In this problem, we demonstrate that for CMAC, a variant that XORs the second key 
after applying the final encryption doesn’t work. Let us consider this for the case 
of the message being an integer multiple of the block size. Then, the variant 
can be expressed as VMAC(K, M) = CBC(K, M) @ K;. Now suppose an adversary 
is able to ask for the MACs of three messages: the message 0 = 0”, where n is 
the cipher block size; the message 1 = 1”; and the message 1|I 0. As a result of these 
three queries, the adversary gets Ty = CBC(K, 0) @ Ki; T; = CBC(K, 1) @ K, and 
T) = CBC(K, [CBC(K, 1)]) @ K,. Show that the adversary can compute the correct 
MAC for the (unqueried) message 0 || (7) @ 7). 

In the discussion of subkey generation in CMAC, it states that the block cipher is 
applied to the block that consists entirely of 0 bits. The first subkey is derived from the 
resulting string by a left shift of one bit and, conditionally, by XORing a constant that 
depends on the block size. The second subkey is derived in the same manner from the 
first subkey. 

a. What constants are needed for block sizes of 64 and 128 bits? 

b. Explain how the left shift and XOR accomplishes the desired result. 

Section 12.6 listed three general approaches to authenticated encryption: MtE, EtM, 
and E&M. 

a. Which approach is used by CCM? 

b. Which approach is used by GCM? 


Show that the GHASH function calculates 
(X% . H”) ® (X, ° ey ) ae ® (Xn-1 . HP) <) (Xn : H) 
Draw a figure similar to Figure 12.11 that shows authenticated decryption. 


Alice want to send a single bit of information (a yes or a no) to Bob by means of a 
word of length 2. Alice and Bob have four possible keys avialable to perform message 
authentication. The following matrix shows the 2-bit word sent for each message 
under each key: 


Message 
Key 0 1 
1 00 01 
2 10 00 
3 01 11 
4 11 10 


a. The preceding matrix is in a useful form for Alice. Construct a matrix with the 
same information that would be more useful for Bob. 

b. What is the probability that someone else can successfully impersonate Alice? 

c. What is the probability that someone can replace an intercepted message with 
another message successfully? 
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To guard against the baneful influence exerted by strangers is therefore an 
elementary dictate of savage prudence. Hence before strangers are allowed to 
enter a district, or at least before they are permitted to mingle freely with the 
inhabitants, certain ceremonies are often performed by the natives of the coun- 
try for the purpose of disarming the strangers of their magical powers, or of 
disinfecting, so to speak, the tainted atmosphere by which they are supposed to 
be surrounded. 


—The Golden Bough, Sir James George Frazer 


KEY POINTS 


® A digital signature is an authentication mechanism that enables the 
creator of a message to attach a code that acts as a signature. Typically 
the signature is formed by taking the hash of the message and encrypting 
the message with the creator’s private key. The signature guarantees the 
source and integrity of the message. 


© The digital signature standard (DSS) is an NIST standard that uses the 
secure hash algorithm (SHA). 


The most important development from the work on public-key cryptography is the 
digital signature. The digital signature provides a set of security capabilities that would 
be difficult to implement in any other way. 

Figure 13.1 is a generic model of the process of making and using digital signa- 
tures. Bob can sign a message using a digital signature generation algorithm. The inputs 
to the algorithm are the message and Bob’s private key. Any other user, say Alice, can 
verify the signature using a verification algorithm, whose inputs are the message, the 
signature, and Bob’s public key. In simplified terms, the essence of the digital signature 
mechanism is shown in Figure 13.2. This repeats the logic shown in Figure 11.3. 
A worked-out example, using RSA, is available at this book’s Web site. 

We begin this chapter with an overview of digital signatures. Then, we introduce 
the Digital Signature Standard (DSS). 


13.1 DIGITAL SIGNATURES 


Properties 


Message authentication protects two parties who exchange messages from any third 
party. However, it does not protect the two parties against each other. Several forms 
of dispute between the two are possible. 
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Figure 13.1 Generic Model of Digital Signature Process 


For example, suppose that John sends an authenticated message to Mary, 


using one of the schemes of Figure 12.1. Consider the following disputes that 
could arise. 


1. 


nN 


Mary may forge a different message and claim that it came from John. Mary 
would simply have to create a message and append an authentication code 
using the key that John and Mary share. 


. John can deny sending the message. Because it is possible for Mary to 


forge a message, there is no way to prove that John did in fact send the 
message. 


Both scenarios are of legitimate concern. Here is an example of the first sce- 


nario: An electronic funds transfer takes place, and the receiver increases the amount 
of funds transferred and claims that the larger amount had arrived from the sender. 
An example of the second scenario is that an electronic mail message contains 
instructions to a stockbroker for a transaction that subsequently turns out badly. The 
sender pretends that the message was never sent. 
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Figure 13.2 Simplified Depiction of Essential Elements of Digital Signature Process 


In situations where there is not complete trust between sender and receiver, 
something more than authentication is needed. The most attractive solution to 
this problem is the digital signature. The digital signature must have the following 
properties: 

e It must verify the author and the date and time of the signature. 
e It must authenticate the contents at the time of the signature. 
e It must be verifiable by third parties, to resolve disputes. 


Thus, the digital signature function includes the authentication function. 


Attacks and Forgeries 


[GOLD83] lists the following types of attacks, in order of increasing severity. Here 
A denotes the user whose signature method is being attacked, and C denotes the 
attacker. 


13.1 / DIGITAL SIGNATURES 399 


Key-only attack: C only knows A’s public key. 


Known message attack: C is given access to a set of messages and their 
signatures. 


Generic chosen message attack: C chooses a list of messages before attempt- 
ing to breaks A’s signature scheme, independent of A’s public key. C then 
obtains from A valid signatures for the chosen messages. The attack is generic, 
because it does not depend on A’s public key; the same attack is used against 
everyone. 

Directed chosen message attack: Similar to the generic attack, except that the 
list of messages to be signed is chosen after C knows A’s public key but before 
any signatures are seen. 

Adaptive chosen message attack: C is allowed to use A as an “oracle.” This 
means the A may request signatures of messages that depend on previously 
obtained message-signature pairs. 


[GOLD88] then defines success at breaking a signature scheme as an outcome 


in which C can do any of the following with a non-negligible probability: 


Total break: C determines A’s private key. 

Universal forgery: C finds an efficient signing algorithm that provides an 
equivalent way of constructing signatures on arbitrary messages. 

Selective forgery: C forges a signature for a particular message chosen 
by C. 

Existential forgery: C forges a signature for at least one message. C has 


no control over the message. Consequently, this forgery may only be a minor 
nuisance to A. 


Digital Signature Requirements 


On the basis of the properties and attacks just discussed, we can formulate the fol- 
lowing requirements for a digital signature. 


The signature must be a bit pattern that depends on the message being 
signed. 


The signature must use some information unique to the sender to prevent 
both forgery and denial. 


It must be relatively easy to produce the digital signature. 
It must be relatively easy to recognize and verify the digital signature. 


It must be computationally infeasible to forge a digital signature, either by 
constructing a new message for an existing digital signature or by constructing 
a fraudulent digital signature for a given message. 


It must be practical to retain a copy of the digital signature in storage. 


A secure hash function, embedded in a scheme such as that of Figure 13.2, provides 
a basis for satisfying these requirements. However, care must be taken in the design 
of the details of the scheme. 
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Direct Digital Signature 


The term direct digital signature refers to a digital signature scheme that involves 
only the communicating parties (source, destination). It is assumed that the destina- 
tion knows the public key of the source. 

Confidentiality can be provided by encrypting the entire message plus signa- 
ture with a shared secret key (symmetric encryption). Note that it is important to 
perform the signature function first and then an outer confidentiality function. In 
case of dispute, some third party must view the message and its signature. If the 
signature is calculated on an encrypted message, then the third party also needs 
access to the decryption key to read the original message. However, if the signature 
is the inner operation, then the recipient can store the plaintext message and its sig- 
nature for later use in dispute resolution. 

The validity of the scheme just described depends on the security of the 
sender’s private key. If a sender later wishes to deny sending a particular message, 
the sender can claim that the private key was lost or stolen and that someone else 
forged his or her signature. Administrative controls relating to the security of pri- 
vate keys can be employed to thwart or at least weaken this ploy, but the threat is 
still there, at least to some degree. One example is to require every signed message 
to include a timestamp (date and time) and to require prompt reporting of compro- 
mised keys to a central authority. 

Another threat is that some private key might actually be stolen from X at 
time T. The opponent can then send a message signed with X’s signature and 
stamped with a time before or equal to T. 

The universally accepted technique for dealing with these threats is the 
use of a digital certificate and certificate authorities. We defer a discussion 
of this topic until Chapter 14, and focus in this chapter on digital signature 
algorithms. 


13.2 ELGAMAL DIGITAL SIGNATURE SCHEME 


Before examining the NIST Digital Signature standard, it will be helpful to under- 
stand the ElGamal and Schnorr signature schemes. Recall from Chapter 10, that the 
ElGamal encryption scheme is designed to enable encryption by a user’s public key 
with decryption by the user’s private key. The ElGamal signature scheme involves 
the use of the private key for encryption and the public key for decryption 
[ELGA84, ELGA85]. 

Before proceeding, we need a result from number theory. Recall from Chapter 8 
that for a prime number q, if a is a primitive root of g, then 


a,a’, ...,at! 
are distinct (mod q). It can be shown that, if a is a primitive root of g, then 
1. For any integer m, a" = 1(mod q) if and only if m = 0(mod q — 1). 
2. For any integers, i, j,a’ = a/ (mod q) if and only if i = j(mod q — 1). 
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As with ElGamal encryption, the global elements of ElGamal digital signature 
are a prime number gq and a, which is a primitive root of g. User A generates a 
private/public key pair as follows. 


1. Generate a random integer X,,such that 1 < X, <q -— 1. 
2. Compute Y4 = a*4modq. 
3. A’s private key is X4;A’s pubic key is {q, a, Y4}. 
To sign a message M, user A first computes the hash m = H(M), such that m 


is an integer in the range 0 = m = gq — 1.A then forms a digital signature as 
follows. 


1. Choose a random integer K such that 1 = K = q — 1 and ged(K,q — 1) = 1. 
That is, K is relatively prime to g — 1. 


2. Compute S; = a“ mod gq. Note that this is the same as the computation of C; 
for ElGamal encryption. 

3. Compute K~'mod(q — 1). That is, compute the inverse of K modulo q — 1. 

4. Compute S, = K~'(m — X 4S)mod (q — 1). 

5. The signature consists of the pair (S;, 5). 


Any user B can verify the signature as follows. 
1. Compute V; = a” mod q. 
2. Compute Vz = (Y¥,4)°'(S,)mod q. 


The signature is valid if V; = V>. Let us demonstrate that this is so. Assume 
that the equality is true. Then we have 


a” mod q = (Y4)°(S;)2mod qg assume V; = V> 

a” mod gq = aX*4SiakS mod q substituting for ¥, and S$, 
a’ *4Si mod q = a mod q rearranging terms 

m — XS, = KS, mod (q — 1) property of primitive roots 


m — X,S; = KK~!(m — X,S;) mod (q — 1) substituting for S, 


For example, let us start with the prime field GF(19); that is, g = 19. It has 
primitive roots {2, 3, 10, 13, 14, 15}, as shown in Table 8.3. We choose a = 10. 
Alice generates a key pair as follows: 


. Alice chooses X, = 16. 
. Then Y, = a mod g = a!’ mod 19 = 4. 
. Alice’s private key is 16; Alice’s pubic key is {g, a, Y%4} = {19, 10, 4}. 


eo NR = 


Suppose Alice wants to sign a message with hash value m = 14. 


1. Alice chooses K = 5, which is relatively prime to g — 1 = 18. 
2. S; = aXmod q = 10°mod 19 = 3 (see Table 8.3). 
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3. K-'mod (q — 1) = 5-'mod 18 = 11. 
4, S,) = K"'(m — X,S,)mod (q — 1) = 11(14 — (16)(3))mod 18 = —374 
mod 18 = 4. 


Bob can verify the signature as follows. 


1. V; = a&"mod q = 10'* mod 19 = 16. 
2. Vy = (Y)*(S,) mod g = (4°)(34) mod 19 = 5184 mod 19 = 16. 


Thus, the signature is valid. 


13.3 SCHNORR DIGITAL SIGNATURE SCHEME 


As with the ElGamal digital signature scheme, the Schnorr signature scheme 
is based on discrete logarithms [SCHN89, SCHN91]. The Schnorr scheme 
minimizes the message-dependent amount of computation required to generate a 
signature. The main work for signature generation does not depend on the message 
and can be done during the idle time of the processor. The message-dependent part 
of the signature generation requires multiplying a 2n-bit integer with an n-bit 
integer. 

The scheme is based on using a prime modulus p, with p — 1 having a prime 
factor q of appropriate size; that is, p — 1 = (mod q). Typically, we use p ~ 214 
and q ~ 2!°. Thus, p is a 1024-bit number, and q is a 160-bit number, which is also 
the length of the SHA-1 hash value. 

The first part of this scheme is the generation of a private/public key pair, 
which consists of the following steps. 


1. Choose primes p and q, such that g is a prime factor of p — 1. 


2. Choose an integer a, such that a? = 1mod p. The values a, p, and g comprise a 
global public key that can be common to a group of users. 


io) 


. Choose a random integer s with 0 < s < q.This is the user’s private key. 
4. Calculate v = a~* mod p. This is the user’s public key. 


A user with private key s and public key v generates a signature as 
follows. 


1. Choose a random integer r with 0 < r < q and compute x = a’mod p. This 
computation is a preprocessing stage independent of the message M to be 
signed. 


2. Concatenate the message with x and hash the result to compute the value e: 
e = H(M || x) 


3. Compute y = (r + se)mod q. The signature consists of the pair (e, y). 
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Any other user can verify the signature as follows. 


1. Compute x’ = a’v’mod p. 
2. Verify that e = H(M |I x’). 


To see that the verification works, observe that 


x = ev =aa =a =a = x(modp) 


Hence, H(M || x’) = H(M |I x). 


13.4 DIGITAL SIGNATURE STANDARD 


The National Institute of Standards and Technology (NIST) has published Federal 
Information Processing Standard FIPS 186, known as the Digital Signature 
Standard (DSS). The DSS makes use of the Secure Hash Algorithm (SHA) 
described in Chapter 12 and presents a new digital signature technique, the Digital 
Signature Algorithm (DSA). The DSS was originally proposed in 1991 and revised 
in 1993 in response to public feedback concerning the security of the scheme. There 
was a further minor revision in 1996. In 2000, an expanded version of the standard 
was issued as FIPS 186-2, subsequently updated to FIPS 186-3 in 2009. This latest 
version also incorporates digital signature algorithms based on RSA and on elliptic 
curve cryptography. In this section, we discuss the original DSS algorithm. 


The DSS Approach 


The DSS uses an algorithm that is designed to provide only the digital signature 
function. Unlike RSA, it cannot be used for encryption or key exchange. 
Nevertheless, it is a public-key technique. 

Figure 13.3 contrasts the DSS approach for generating digital signatures to 
that used with RSA. In the RSA approach, the message to be signed is input to a 
hash function that produces a secure hash code of fixed length. This hash code is 
then encrypted using the sender’s private key to form the signature. Both the mes- 
sage and the signature are then transmitted. The recipient takes the message and 
produces a hash code. The recipient also decrypts the signature using the sender’s 
public key. If the calculated hash code matches the decrypted signature, the signa- 
ture is accepted as valid. Because only the sender knows the private key, only the 
sender could have produced a valid signature. 

The DSS approach also makes use of a hash function. The hash code is pro- 
vided as input to a signature function along with a random number k generated for 
this particular signature. The signature function also depends on the sendet’s private 
key (PR,) and a set of parameters known to a group of communicating principals. 
We can consider this set to constitute a global public key (PUG).! The result is a sig- 
nature consisting of two components, labeled s and r. 


'It is also possible to allow these additional parameters to vary with each user so that they are a part of a 
user’s public key. In practice, it is more likely that a global public key will be used that is separate from 
each user’s public key. 
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Compare 


E(PR,, H™)] 
(a) RSA approach 


(b) DSS approach 
Figure 13.3 Two Approaches to Digital Signatures 


At the receiving end, the hash code of the incoming message is generated. This 
plus the signature is input to a verification function. The verification function also 
depends on the global public key as well as the sender’s public key (PU,), which is 
paired with the sender’s private key. The output of the verification function is a 
value that is equal to the signature component r if the signature is valid. The signa- 
ture function is such that only the sender, with knowledge of the private key, could 
have produced the valid signature. 

We turn now to the details of the algorithm. 


The Digital Signature Algorithm 


The DSA is based on the difficulty of computing discrete logarithms (see Chapter 8) 
and is based on schemes originally presented by ElGamal [ELGA85] and Schnorr 
[SCHN91]. 

Figure 13.4 summarizes the algorithm. There are three parameters that are pub- 
lic and can be common to a group of users. A 160-bit prime number q is chosen. Next, 
a prime number P is selected with a length between 512 and 1024 bits such that 9 
divides (p — 1). Finally, g is chosen to be of the form h?~) mod p, where h is an 
integer between 1 and (p — 1) with the restriction that g must be greater than is 
Thus, the global public-key components of DSA have the same for as in the Schnorr 
signature scheme. 

With these numbers in hand, each user selects a private key and generates a 
public key. The private key x must be a number from 1 to (gq — 1) and should be cho- 
sen randomly or pseudorandomly. The public key is calculated from the private key 
as y = g' mod p. The calculation of y given x is relatively straightforward. However, 
given the public key y, it is believed to be computationally infeasible to determine x, 
which is the discrete logarithm of y to the base g, modp (see Chapter 8). 


?In number-theoretic terms, g is of order q mod p; see Chapter 8. 


Global Public-Key Components 


prime number where 2! ~! < p < 2! 

for 512 = L = 1024 and La multiple of 64; 
i.e., bit length of between 512 and 1024 bits 
in increments of 64 bits 
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Signing 
r = (g* mod p) mod g 


s =[k!(H(M) + xn] mod g 


Signature = (7; s) 
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prime divisor of (p — 1), where 2!°? < g < 2!°°; 
ie., bit length of 160 bits 

Verifying 
= h?~ 4 mod p, 
where hi is any integer with 1 <h < (p — 1) 
such that h? ~ "4 mod p > 1 


c= (s’)! mod q 
u, = [H(M’)w] mod g 
uy = (r’)w mod g 


User’s Private Key ul ya 


o =| ) mod p] mod q 


random or pseudorandom integer with 0 < x <q TEST: v =r’ 


User’s Public Key M = message to be signed 
H(M) = hash of M using SHA-1 
M',r', s’ = received versions of M, r, s 


User's Per-Message Secret Number 


k =random or pseudorandom integer with 0 < k < q 


Figure 13.4 The Digital Signature Algorithm (DSA) 


To create a signature, a user calculates two quantities, r and s, that are func- 
tions of the public key components (p, g, g), the user’s private key (x), the hash 
code of the message H(M), and an additional integer k that should be generated 
randomly or pseudorandomly and be unique for each signing. 

At the receiving end, verification is performed using the formulas shown in 
Figure 13.4. The receiver generates a quantity v that is a function of the public key com- 
ponents, the sender’s public key, and the hash code of the incoming message. If this 
quantity matches the r component of the signature, then the signature is validated. 

Figure 13.5 depicts the functions of signing and verifying. 

The structure of the algorithm, as revealed in Figure 13.5, is quite interesting. 
Note that the test at the end is on the value 7, which does not depend on the message 
at all. Instead, r is a function of & and the three global public-key components. The 
multiplicative inverse of k (mod q) is passed to a function that also has as inputs the 
message hash code and the user’s private key. The structure of this function is such 
that the receiver can recover r using the incoming message and signature, the public 
key of the user, and the global public key. It is certainly not obvious from Figure 13.4 
or Figure 13.5 that such a scheme would work. A proof is provided in Appendix K. 

Given the difficulty of taking discrete logarithms, it is infeasible for an oppo- 
nent to recover k from r or to recover x from s. 

Another point worth noting is that the only computationally demanding task 
in signature generation is the exponential calculation g‘mod p. Because this value 
does not depend on the message to be signed, it can be computed ahead of time. 
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Compare 


s = f,(H(M), k, x, 7, q) = (k7~! (HM) + xr)) mod q w = f3(s', g)= (s’)7! mod q 


r= f,(k, p, 4, 8) = (¢* mod p) mod q v= fy, g, 8, HW’), w, 1’) 
= (gO) mold yw mee 4) mod p) mod q 
(a) Signing (b) Verifying 
Figure 13.5 DSS Signing and Verifying 


Indeed, a user could precalculate a number of values of r to be used to sign 
documents as needed. The only other somewhat demanding task is the determina- 
tion of a multiplicative inverse, k~!. Again, a number of these values can be 
precalculated. 


13.5 RECOMMENDED READING AND WEB SITE 


[AKL83] is the classic paper on digital signatures and is still highly relevant. A more recent, 
and excellent, survey is [MITC92]. 


AKL83 AKI, S. “Digital Signatures: A Tutorial Survey.” Computer, February 1983. 


MITC92 Mitchell, C.; Piper, F. ; and Wild, P. “Digital Signatures.” In [SIMM92a]. 


Recommended Web Site: 


e Digital Signatures: NIST page with information on NIST-approved digital signature 
options. 
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13.6 KEY TERM, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


direct digital signature digital signature standard Schnorr digital signature 
digital signature (DSS) timestamp 


digital signature algorithm ElGamal digital signature 


(DSA) 


Review Questions 


13.1 List two disputes that can arise in the context of message authentication. 

13.2 What are the properties a digital signature should have? 

13.3. What requirements should a digital signature scheme satisfy? 

13.4 What is the difference between direct and arbitrated digital signature? 

13.5 In what order should the signature function and the confidentiality function be 

applied to a message, and why? 

13.6 What are some threats associated with a direct digital signature scheme? 
Problems 

13.1 Dr. Watson patiently waited until Sherlock Holmes finished. “Some interesting prob- 


lem to solve, Holmes?” he asked when Holmes finally logged out. 

“Oh, not exactly. I merely checked my e-mail and then made a couple of net- 
work experiments instead of my usual chemical ones. I have only one client now and 
I have already solved his problem. If I remember correctly, you once mentioned cryp- 
tology among your other hobbies, so it may interest you.” 

“Well, lam only an amateur cryptologist, Holmes. But of course I am interested 
in the problem. What is it about?” 

“My client is Mr. Hosgrave, director of a small but progressive bank. The bank 
is fully computerized and of course uses network communications extensively. The 
bank already uses RSA to protect its data and to digitally sign documents that are 
communicated. Now the bank wants to introduce some changes in its procedures; in 
particular, it needs to digitally sign some documents by two signatories. 


1. The first signatory prepares the document, forms its signature, and passes the doc- 
ument to the second signatory. 

2. The second signatory as a first step must verify that the document was really 
signed by the first signatory. She then incorporates her signature into the docu- 
ment’s signature so that the recipient, as well as any member of the public, may 
verify that the document was indeed signed by both signatories. In addition, only 
the second signatory has to be able to verify the document’s signature after the 
first step; that is, the recipient (or any member of the public) should be able to 
verify only the complete document with signatures of both signatories, but not the 
document in its intermediate form where only one signatory has signed it. 
Moreover, the bank would like to make use of its existing modules that support 
RSA-style digital signatures.” 

“Hm, I understand how RSA can be used to digitally sign documents by one signa- 

tory, Holmes. I guess you have solved the problem of Mr. Hosgrave by appropriate 

generalization of RSA digital signatures.” 
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“Exactly, Watson,” nodded Sherlock Holmes. “Originally, the RSA digital sig- 
nature was formed by encrypting the document by the signatory’s private decryption 
key ‘d’, and the signature could be verified by anyone through its decryption using 
publicly known encryption key ‘e’. One can verify that the signature S was formed by 
the person who knows d, which is supposed to be the only signatory. Now the problem 
of Mr. Hosgrave can be solved in the same way by slight generalization of the process, 
that is ...” 

Finish the explanation. 

DSA specifies that if the signature generation process results in a value of s = 0,a 

new value of k should be generated and the signature should be recalculated. Why? 

What happens if a k value used in creating a DSA signature is compromised? 

The DSS document includes a recommended algorithm for testing a number for 

primality. 

1. [Choose w] Let w be a random odd integer. Then (w — 1) is even and can be 
expressed in the form 2“m with m odd. That is, 2“ is the largest power of 2 that 
divides (w — 1). 

2. [Generate b] Let b be a random integer in the range 1 < b < w. 

3. [Exponentiate] Set j = 0 and z = b” mod w. 

4. [Done?] If j = 0 and z = 1, or if z = w — 1, then w passes the test and may be 
prime; go to step 8. 

5. [Terminate?] If j > 0 and z = 1, then w is not prime; terminate algorithm for 
this w. 

6. [Increase j] Set j = j + 1.Ifj < a,set z = z’modw and go to step 4. 

7. [Terminate] w is not prime; terminate algorithm for this w. 

8. [Test again?] If enough random values of b have been tested, then accept w as 
prime and terminate algorithm; otherwise, go to step 2. 


a. Explain how the algorithm works. 

b. Show that it is equivalent to the Miller-Rabin test described in Chapter 8. 

With DSS, because the value of k is generated for each signature, even if the same 
message is signed twice on different occasions, the signatures will differ. This is not 
true of RSA signatures. What is the practical implication of this difference? 
Consider the problem of creating domain parameters for DSA. Suppose we have 
already found primes p and q such that ql(p — 1). Now we need to find ge Z, with g 
of order gmod p. Consider the following two algorithms: 


Algorithm 1 Algorithm 2 
repeat repeat 
select g € Z, select h € Z, 
h<— g?mod p g—h’—?P mod p 
until (1 = 1 and g # 1) until (¢ 4 1) 
return g return g 


a. Prove that the value returned by Algorithm 1 has order q. 

b. Prove that the value returned by Algorithm 2 has order q. 

c. Suppose p = 40193 and q = 157. How many loop iterations do you expect 
Algorithm 1 to make before it finds a generator? 

d. Ifp is 1024 bits and q is 160 bits, would you recommend using Algorithm 1 to find g? 
Explain. 

e. Suppose p = 40193 and g = 157. What is the probability that Algorithm 2 com- 
putes a generator in its very first loop iteration? (If it is helpful, you may use the 


fact that >) g(d) = n when answering this question.) 
d\n 
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It is tempting to try to develop a variation on Diffie-Hellman that could be used as a 
digital signature. Here is one that is simpler than DSA and that does not require a 
secret random number in addition to the private key. 


Public elements; gq prime number 
a a< qandaisa primitive root of g 


Private key: Xx X <q 


Public key: Y = a* modq 


To sign a message M, compute h = H(M), which is the hash code of the message. We 
require that gcd(h, gq — 1) = 1.Ifnot, append the hash to the message and calculate a 
new hash. Continue this process until a hash code is produced that is 
relatively prime to (q — 1).Then calculate Z to satisfy Z X h = X(modq — 1). The 
signature of the message is a~. To verify the signature, a user verifies that 
Y = (a”)" = a*mod g. 
a. Show that this scheme works. That is, show that the verification process produces 
an equality if the signature is valid. 
b. Show that the scheme is unacceptable by describing a simple technique for forg- 
ing a user’s signature on an arbitrary message. 
An early proposal for a digital signature scheme using symmetric encryption is based 
on the following. To sign an n-bit message, the sender randomly generates in advance 
2n 56-bit cryptographic keys: 
k1, K1, k2, K2, ...,kn, Kn 


which are kept private. The sender prepares in advance two sets of corresponding 
non-secret 64-bit validation parameters, which are made public: 


ul, U1, u2, U2, ...,un, Un and v1, V1, v2, V2,...,vn, Vn 
where 
vi = E(ki, ui), Vi = E(ki, Ui) 


The message M is signed as follows. For the ith bit of the message, either ki or Ki is 

attached to the message, depending on whether the message bit is 0 or 1. For example, 

if the first three bits of the message are 011, then the first three keys of the signature 

are k1, K2, K3. 

a. How does the receiver validate the message? 

b. Is the technique secure? 

c. How many times can the same set of secret keys be safely used for different 
messages? 

d. What, if any, practical problems does this scheme present? 
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No Singhalese, whether man or woman, would venture out of the house without 
a bunch of keys in his hand, for without such a talisman he would fear that some 
devil might take advantage of his weak state to slip into his body. 


—The Golden Bough, Sir James George Frazer 


John wrote the letters of the alphabet under the letters in its first lines and tried 
it against the message. Immediately he knew that once more he had broken the 
code. It was extraordinary the feeling of triumph he had. He felt on top of the 
world. For not only had he done it, had he broken the July code, but he now 
had the key to every future coded message, since instructions as to the source 
of the next one must of necessity appear in the current one at the end of each 
month. 


—Talking to Strange Men, Ruth Rendall 


KEY POINTS 


® Key distribution is the function that delivers a key to two parties who 
wish to exchange secure encrypted data. Some sort of mechanism or pro- 
tocol is needed to provide for the secure distribution of keys. 


® Key distribution often involves the use of master keys, which are infre- 
quently used and are long lasting, and session keys, which are generated 
and distributed for temporary use between two patties. 

® Public-key encryption schemes are secure only if the authenticity of the 
public key is assured. A public-key certificate scheme provides the neces- 
sary security. 

® X.509 defines the format for public-key certificates. This format is widely 
used in a variety of applications. 

© A public-key infrastructure (PKI) is defined as the set of hardware, 
software, people, policies, and procedures needed to create, manage, 
store, distribute, and revoke digital certificates based on asymmetric 
cryptography. 

® Typically, PKI implementations make use of X.509 certificates. 


The topics of cryptographic key management and cryptographic key distribution are 
complex, involving cryptographic, protocol, and management considerations. The pur- 
pose of this chapter is to give the reader a feel for the issues involved and a broad sur- 
vey of the various aspects of key management and distribution. For more information, 
the place to start is the three-volume NIST SP 800-57, followed by the recommended 


readings listed at the end of this chapter. 
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14.1 SYMMETRIC KEY DISTRIBUTION 


USING SYMMETRIC ENCRYPTION 


For symmetric encryption to work, the two parties to an exchange must share the 
same key, and that key must be protected from access by others. Furthermore, fre- 
quent key changes are usually desirable to limit the amount of data compromised if 
an attacker learns the key. Therefore, the strength of any cryptographic system 
rests with the key distribution technique, a term that refers to the means of deliver- 
ing a key to two parties who wish to exchange data without allowing others to see 
the key. For two parties A and B, key distribution can be achieved in a number of 
ways, as follows: 


= 


. A can select a key and physically deliver it to B. 
. A third party can select the key and physically deliver it to A and B. 


ww NM 


. If A and B have previously and recently used a key, one party can transmit the 
new key to the other, encrypted using the old key. 


4. If A and B each has an encrypted connection to a third party C, C can deliver 
a key on the encrypted links to A and B. 


Options 1 and 2 call for manual delivery of a key. For link encryption, this is a 
reasonable requirement, because each link encryption device is going to be exchang- 
ing data only with its partner on the other end of the link. However, for end-to-end 
encryption over a network, manual delivery is awkward. In a distributed system, any 
given host or terminal may need to engage in exchanges with many other hosts and 
terminals over time. Thus, each device needs a number of keys supplied dynamically. 
The problem is especially difficult in a wide-area distributed system. 

The scale of the problem depends on the number of communicating pairs that 
must be supported. If end-to-end encryption is done at a network or IP level, then a 
key is needed for each pair of hosts on the network that wish to communicate. Thus, 
if there are N hosts, the number of required keys is [V(N — 1)]/2. If encryption is 
done at the application level, then a key is needed for every pair of users or 
processes that require communication. Thus, a network may have hundreds of hosts 
but thousands of users and processes. Figure 14.1 illustrates the magnitude of the 
key distribution task for end-to-end encryption.! A network using node-level 
encryption with 1000 nodes would conceivably need to distribute as many as half a 
million keys. If that same network supported 10,000 applications, then as many as 
50 million keys may be required for application-level encryption. 

Returning to our list, option 3 is a possibility for either link encryption or end- 
to-end encryption, but if an attacker ever succeeds in gaining access to one key, then 
all subsequent keys will be revealed. Furthermore, the initial distribution of poten- 
tially millions of keys still must be made. 


'Note that this figure uses a log-log scale, so that a linear graph indicates exponential growth. A basic 
review of log scales is in the math refresher document at the Computer Science Student Resource Site at 
WilliamStallings.com/StudentSupport.html. 
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Figure 14.1 Number of Keys Required to Support Arbitrary Connections 
between Endpoints 


For end-to-end encryption, some variation on option 4 has been widely 
adopted. In this scheme, a key distribution center is responsible for distributing keys 
to pairs of users (hosts, processes, applications) as needed. Each user must share a 
unique key with the key distribution center for purposes of key distribution. 

The use of a key distribution center is based on the use of a hierarchy of keys. 
At a minimum, two levels of keys are used (Figure 14.2). Communication between 
end systems is encrypted using a temporary key, often referred to as a session key. 
Typically, the session key is used for the duration of a logical connection, such as a 
frame relay connection or transport connection, and then discarded. Each session 
key is obtained from the key distribution center over the same networking facilities 
used for end-user communication. Accordingly, session keys are transmitted in 
encrypted form, using a master key that is shared by the key distribution center and 
an end system or user. 

For each end system or user, there is a unique master key that it shares with 
the key distribution center. Of course, these master keys must be distributed in some 
fashion. However, the scale of the problem is vastly reduced. If there are N entities 
that wish to communicate in pairs, then, as was mentioned, as many as [N(N — 1)]/2 
session keys are needed at any one time. However, only N master keys are required, 
one for each entity. Thus, master keys can be distributed in some noncryptographic 
way, such as physical delivery. 
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Figure 14.2. The Use of a Key Hierarchy 


A Key Distribution Scenario 


The key distribution concept can be deployed in a number of ways. A typical sce- 
nario is illustrated in Figure 14.3, which is based on a figure in [POPE79]. The sce- 
nario assumes that each user shares a unique master key with the key distribution 
center (KDC). 
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Figure 14.3 Key Distribution Scenario 
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Let us assume that user A wishes to establish a logical connection with B and 


requires a one-time session key to protect the data transmitted over the connection. 
A has a master key, K,, known only to itself and the KDC; similarly, B shares the 
master key K, with the KDC. The following steps occur. 


1. 


N 


A issues a request to the KDC for a session key to protect a logical connection 
to B. The message includes the identity of A and B and a unique identifier, Nj, 
for this transaction, which we refer to as a nonce. The nonce may be a time- 
stamp, a counter, or a random number; the minimum requirement is that it dif- 
fers with each request. Also, to prevent masquerade, it should be difficult for 
an opponent to guess the nonce. Thus, a random number is a good choice for a 
nonce. 


. The KDC responds with a message encrypted using K,. Thus, A is the only one 


who can successfully read the message, and A knows that it originated at the 
KDC. The message includes two items intended for A: 


e The one-time session key, K,, to be used for the session 


e The original request message, including the nonce, to enable A to match 
this response with the appropriate request 


Thus, A can verify that its original request was not altered before reception by 
the KDC and, because of the nonce, that this is not a replay of some previous 
request. 


In addition, the message includes two items intended for B: 
e The one-time session key, K,, to be used for the session 
e An identifier of A (e.g.,its network address), ID, 


These last two items are encrypted with K;, (the master key that the KDC shares 
with B). They are to be sent to B to establish the connection and prove A’s identity. 


. A stores the session key for use in the upcoming session and forwards to B the 


information that originated at the KDC for B, namely, E(K,,[K,||[D,]). 
Because this information is encrypted with K,, it is protected from eavesdrop- 
ping. B now knows the session key (K,), knows that the other party is A (from 
ID,), and knows that the information originated at the KDC (because it is 
encrypted using K;,). 


At this point, a session key has been securely delivered to A and B, and 


they may begin their protected exchange. However, two additional steps are 
desirable: 


4. 


5. 


Using the newly minted session key for encryption, B sends a nonce, N>, to A. 


Also, using K,, A responds with f(V>), where f is a function that performs some 
transformation on N,j (e.g., adding one). 


These steps assure B that the original message it received (step 3) was not a 
replay. 


Note that the actual key distribution involves only steps 1 through 3, but that 


steps 4 and 5, as well as step 3, perform an authentication function. 
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Hierarchical Key Control 


It is not necessary to limit the key distribution function to a single KDC. Indeed, for 
very large networks, it may not be practical to do so. As an alternative, a hierarchy of 
KDCs can be established. For example, there can be local KDCs, each responsible 
for a small domain of the overall internetwork, such as a single LAN or a single 
building. For communication among entities within the same local domain, the local 
KDC is responsible for key distribution. If two entities in different domains desire a 
shared key, then the corresponding local KDCs can communicate through a global 
KDC. In this case, any one of the three KDCs involved can actually select the key. 
The hierarchical concept can be extended to three or even more layers, depending 
on the size of the user population and the geographic scope of the internetwork. 

A hierarchical scheme minimizes the effort involved in master key distribu- 
tion, because most master keys are those shared by a local KDC with its local enti- 
ties. Furthermore, such a scheme limits the damage of a faulty or subverted KDC to 
its local area only. 


Session Key Lifetime 


The more frequently session keys are exchanged, the more secure they are, because 
the opponent has less ciphertext to work with for any given session key. On the 
other hand, the distribution of session keys delays the start of any exchange and 
places a burden on network capacity. A security manager must try to balance these 
competing considerations in determining the lifetime of a particular session key. 

For connection-oriented protocols, one obvious choice is to use the same ses- 
sion key for the length of time that the connection is open, using a new session key 
for each new session. If a logical connection has a very long lifetime, then it would 
be prudent to change the session key periodically, perhaps every time the PDU 
(protocol data unit) sequence number cycles. 

For a connectionless protocol, such as a transaction-oriented protocol, there is 
no explicit connection initiation or termination. Thus, it is not obvious how often 
one needs to change the session key. The most secure approach is to use a new ses- 
sion key for each exchange. However, this negates one of the principal benefits of 
connectionless protocols, which is minimum overhead and delay for each transac- 
tion. A better strategy is to use a given session key for a certain fixed period only or 
for a certain number of transactions. 


A Transparent Key Control Scheme 


The approach suggested in Figure 14.3 has many variations, one of which is 
described in this subsection. The scheme (Figure 14.4) is useful for providing end-to- 
end encryption at a network or transport level in a way that is transparent to the end 
users. The approach assumes that communication makes use of a connection-ori- 
ented end-to-end protocol, such as TCP. The noteworthy element of this approach is 
a session security module (SSM), which may consist of functionality at one protocol 
layer, that performs end-to-end encryption and obtains session keys on behalf of its 
host or terminal. 
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1. Host sends packet requesting connection. 
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Figure 14.4 Automatic Key Distribution for Connection-Oriented Protocol 
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The steps involved in establishing a connection are shown in Figure 14.4. 
When one host wishes to set up a connection to another host, it transmits a connec- 
tion-request packet (step 1). The SSM saves that packet and applies to the KDC for 
permission to establish the connection (step 2). The communication between the 
SSM and the KDC is encrypted using a master key shared only by this SSM and the 
KDC. If the KDC approves the connection request, it generates the session key and 
delivers it to the two appropriate SSMs, using a unique permanent key for each SSM 
(step 3). The requesting SSM can now release the connection request packet, and a 
connection is set up between the two end systems (step 4). All user data exchanged 
between the two end systems are encrypted by their respective SSMs using the one- 
time session key. 

The automated key distribution approach provides the flexibility and dynamic 
characteristics needed to allow a number of terminal users to access a number of 
hosts and for the hosts to exchange data with each other. 


Decentralized Key Control 


The use of a key distribution center imposes the requirement that the KDC be 
trusted and be protected from subversion. This requirement can be avoided if key 
distribution is fully decentralized. Although full decentralization is not practical for 
larger networks using symmetric encryption only, it may be useful within a local 
context. 

A decentralized approach requires that each end system be able to communi- 
cate in a secure manner with all potential partner end systems for purposes of ses- 
sion key distribution. Thus, there may need to be as many as [n(n — 1)]/2 master 
keys for a configuration with 1 end systems. 

A session key may be established with the following sequence of steps 
(Figure 14.5). 


1. A issues a request to B for a session key and includes a nonce, Nj. 


2. B responds with a message that is encrypted using the shared master key. The 
response includes the session key selected by B, an identifier of B, the value f(V), 
and another nonce, N>. 


3. Using the new session key, A returns f(N2) to B. 
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Figure 14.5 Decentralized Key Distribution 
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Thus, although each node must maintain at most (n — 1) master keys, as many 
session keys as required may be generated and used. Because the messages trans- 
ferred using the master key are short, cryptanalysis is difficult. As before, session 
keys are used for only a limited time to protect them. 


Controlling Key Usage 


The concept of a key hierarchy and the use of automated key distribution 
techniques greatly reduce the number of keys that must be manually managed and 
distributed. It also may be desirable to impose some control on the way in which 
automatically distributed keys are used. For example, in addition to separating mas- 
ter keys from session keys, we may wish to define different types of session keys on 
the basis of use, such as 


e Data-encrypting key, for general communication across a network 


e PIN-encrypting key, for personal identification numbers (PINs) used in elec- 
tronic funds transfer and point-of-sale applications 


e File-encrypting key, for encrypting files stored in publicly accessible locations 


To illustrate the value of separating keys by type, consider the risk that a 
master key is imported as a data-encrypting key into a device. Normally, the mas- 
ter key is physically secured within the cryptographic hardware of the key distrib- 
ution center and of the end systems. Session keys encrypted with this master key 
are available to application programs, as are the data encrypted with such session 
keys. However, if a master key is treated as a session key, it may be possible for an 
unauthorized application to obtain plaintext of session keys encrypted with that 
master key. 

Thus, it may be desirable to institute controls in systems that limit the ways in 
which keys are used, based on characteristics associated with those keys. One simple 
plan is to associate a tag with each key ([JONE82]; see also [DAVI89]). The pro- 
posed technique is for use with DES and makes use of the extra 8 bits in each 64-bit 
DES key. That is, the eight non-key bits ordinarily reserved for parity checking form 
the key tag. The bits have the following interpretation: 


e One bit indicates whether the key is a session key or a master key. 

e One bit indicates whether the key can be used for encryption. 

e One bit indicates whether the key can be used for decryption. 

e The remaining bits are spares for future use. 
Because the tag is embedded in the key, it is encrypted along with the key when that 
key is distributed, thus providing protection. The drawbacks of this scheme are 

1. The tag length is limited to 8 bits, limiting its flexibility and functionality. 

2. Because the tag is not transmitted in clear form, it can be used only at the 


point of decryption, limiting the ways in which key use can be controlled. 


A more flexible scheme, referred to as the control vector, is described in 
[MATY91a and b]. In this scheme, each session key has an associated control vector 
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Figure 14.6 Control Vector Encryption and Decryption 


consisting of a number of fields that specify the uses and restrictions for that session 
key. The length of the control vector may vary. 

The control vector is cryptographically coupled with the key at the time of 
key generation at the KDC. The coupling and decoupling processes are illustrated 
in Figure 14.6. As a first step, the control vector is passed through a hash function 
that produces a value whose length is equal to the encryption key length. Hash 
functions are discussed in detail in Chapter 11. In essence, a hash function maps 
values from a larger range into a smaller range with a reasonably uniform spread. 
Thus, for example, if numbers in the range 1 to 100 are hashed into numbers in the 
range | to 10, approximately 10% of the source values should map into each of the 
target values. 

The hash value is then XORed with the master key to produce an output that 
is used as the key input for encrypting the session key. Thus, 


Hash value = H = h(CV) 
Key input = K,, ® H 
Ciphertext = E([K,, @ H], K,) 


where K,,, is the master key and K, is the session key. The session key is recovered in 
plaintext by the reverse operation: 


D([Kn ® 1], E( Km © H], Ks)) 
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When a session key is delivered to a user from the KDC, it is accompanied 
by the control vector in clear form. The session key can be recovered only by 
using both the master key that the user shares with the KDC and the control 
vector. Thus, the linkage between the session key and its control vector is 
maintained. 

Use of the control vector has two advantages over use of an 8-bit tag. First, 
there is no restriction on length of the control vector, which enables arbitrarily com- 
plex controls to be imposed on key use. Second, the control vector is available in 
clear form at all stages of operation. Thus, control of key use can be exercised in 
multiple locations. 


14.2 SYMMETRIC KEY DISTRIBUTION USING 


ASYMMETRIC ENCRYPTION 


Because of the inefficiency of public key cryptosystems, they are almost never used 
for the direct encryption of sizable block of data, but are limited to relatively small 
blocks. One of the most important uses of a public-key cryptosystem is to encrypt 
secret keys for distribution. We see many specific examples of this in Part Five. Here, 
we discuss general principles and typical approaches. 


Simple Secret Key Distribution 


An extremely simple scheme was put forward by Merkle [MERK79], as illustrated 
in Figure 14.7. If A wishes to communicate with B, the following procedure is 
employed: 
1. A generates a public/private key pair {PU,, PR,} and transmits a message to B 
consisting of PU, and an identifier of A, JD ,. 


2. B generates a secret key, K,, and transmits it to A, which is encrypted with A’s 
public key. 


3. A computes D(PR,, E(PU,, K,)) to recover the secret key. Because only A can 
decrypt the message, only A and B will know the identity of K,. 


4. A discards PU, and PR, and B discards PU,. 


A and B can now securely communicate using conventional encryption and 
the session key K,. At the completion of the exchange, both A and B discard K,. 


CO 
| = 
(2) E(PU,, jo 


Figure 14.7 Simple Use of Public-Key Encryption to Establish a Session Key 
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Despite its simplicity, this is an attractive protocol. No keys exist before the start of 
the communication and none exist after the completion of communication. Thus, the 
risk of compromise of the keys is minimal. At the same time, the communication is 
secure from eavesdropping. 

The protocol depicted in Figure 14.7 is insecure against an adversary who can 
intercept messages and then either relay the intercepted message or substitute 
another message (see Figure 1.3c). Such an attack is known as a man-in-the-middle 
attack [RIVE84]. In this case, if an adversary, E, has control of the intervening com- 
munication channel, then E can compromise the communication in the following 
fashion without being detected. 


1. A generates a public/private key pair {PU,, PR,} and transmits a message 
intended for B consisting of PU, and an identifier of A, ID ,. 


nN 
° 


E intercepts the message, creates its own public/private key pair {PU,, PR,} and 
transmits PU,||/D 4 to B. 


3. B generates a secret key, K,, and transmits E(PU., K,). 
4. E intercepts the message and learns K, by computing D(PR,, E(PU,, K;)). 
E transmits E(PU,, K,) to A. 


mn 
. 


The result is that both A and B know K, and are unaware that K, has also 
been revealed to E. A and B can now exchange messages using K,. E no longer 
actively interferes with the communications channel but simply eavesdrops. 
Knowing K,, E can decrypt all messages, and both A and B are unaware of the 
problem. Thus, this simple protocol is only useful in an environment where the only 
threat is eavesdropping. 


Secret Key Distribution with Confidentiality 
and Authentication 


Figure 14.8, based on an approach suggested in [NEED78], provides protection 
against both active and passive attacks. We begin at a point when it is assumed that 
A and B have exchanged public keys by one of the schemes described subsequently 
in this chapter. Then the following steps occur. 


(1) EU), LN; Il ID4]) 


ae (2) E(PU,, IN; lI Nol) eee 


Initiator Responder. 
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(4) E(PU,, E(PR;, K3)) 
Figure 14.8 Public-Key Distribution of Secret Keys 
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1. 


nN 


A uses B’s public key to encrypt a message to B containing an identifier of 
A(UD 4) and a nonce (N;), which is used to identify this transaction uniquely. 


. Bsends a message to A encrypted with PU, and containing A’s nonce (N;) as 


well as a new nonce generated by B (N>). Because only B could have 
decrypted message (1), the presence of N; in message (2) assures A that the 
correspondent is B. 


. Areturns N, encrypted using B’s public key, to assure B that its correspondent 


is A. 


. Aselects a secret key K, and sends M = E(PU;, E(PR,, K;)) to B. Encryption 


of this message with B’s public key ensures that only B can read it; encryption 
with A’s private key ensures that only A could have sent it. 


-. Bcomputes D(PU,, D(PR,, M)) to recover the secret key. 


The result is that this scheme ensures both confidentiality and authentication 


in the exchange of a secret key. 


A Hybrid Scheme 


Yet another way to use public-key encryption to distribute secret keys is a hybrid 
approach in use on IBM mainframes [LE93]. This scheme retains the use of a key 
distribution center (KDC) that shares a secret master key with each user and 
distributes secret session keys encrypted with the master key. A public key scheme is 
used to distribute the master keys. The following rationale is provided for using this 
three-level approach: 


e Performance: There are many applications, especially transaction-oriented 


applications, in which the session keys change frequently. Distribution of ses- 
sion keys by public-key encryption could degrade overall system performance 
because of the relatively high computational load of public-key encryption 
and decryption. With a three-level hierarchy, public-key encryption is used 
only occasionally to update the master key between a user and the KDC. 


Backward compatibility: The hybrid scheme is easily overlaid on an existing 
KDC scheme with minimal disruption or software changes. 


The addition of a public-key layer provides a secure, efficient means of distrib- 


uting master keys. This is an advantage in a configuration in which a single KDC 
serves a widely distributed set of users. 


14.3 DISTRIBUTION OF PUBLIC KEYS 


Several techniques have been proposed for the distribution of public keys. Virtually 
all these proposals can be grouped into the following general schemes: 


e Public announcement 


e Publicly available directory 


e Public-key authority 


e Public-key certificates 
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Figure 14.9 Uncontrolled Public-Key Distribution 


Public Announcement of Public Keys 


On the face of it, the point of public-key encryption is that the public key is public. 
Thus, if there is some broadly accepted public-key algorithm, such as RSA, any par- 
ticipant can send his or her public key to any other participant or broadcast the key 
to the community at large (Figure 14.9). For example, because of the growing pop- 
ularity of PGP (pretty good privacy, discussed in Chapter 18), which makes use of 
RSA, many PGP users have adopted the practice of appending their public key to 
messages that they send to public forums, such as USENET newsgroups and 
Internet mailing lists. 

Although this approach is convenient, it has a major weakness. Anyone can 
forge such a public announcement. That is, some user could pretend to be user A 
and send a public key to another participant or broadcast such a public key. Until 
such time as user A discovers the forgery and alerts other participants, the forger is 
able to read all encrypted messages intended for A and can use the forged keys for 
authentication (see Figure 9.3). 


Publicly Available Directory 


A greater degree of security can be achieved by maintaining a publicly available 
dynamic directory of public keys. Maintenance and distribution of the public direc- 
tory would have to be the responsibility of some trusted entity or organization 
(Figure 14.10). Such a scheme would include the following elements: 


1. The authority maintains a directory with a {name, public key} entry for each 
participant. 


2. Each participant registers a public key with the directory authority. 
Registration would have to be in person or by some form of secure authenti- 
cated communication. 


3. A participant may replace the existing key with a new one at any time, either 
because of the desire to replace a public key that has already been used for a 
large amount of data, or because the corresponding private key has been com- 
promised in some way. 
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Figure 14.10 Public-Key Publication 


4. Participants could also access the directory electronically. For this purpose, 
secure, authenticated communication from the authority to the participant is 
mandatory. 


This scheme is clearly more secure than individual public announcements but 
still has vulnerabilities. If an adversary succeeds in obtaining or computing the 
private key of the directory authority, the adversary could authoritatively pass out 
counterfeit public keys and subsequently impersonate any participant and eaves- 
drop on messages sent to any participant. Another way to achieve the same end is 
for the adversary to tamper with the records kept by the authority. 


Public-Key Authority 


Stronger security for public-key distribution can be achieved by providing tighter 
control over the distribution of public keys from the directory. A typical scenario is 
illustrated in Figure 14.11, which is based on a figure in [POPE79]. As before, the 
scenario assumes that a central authority maintains a dynamic directory of public 
keys of all participants. In addition, each participant reliably knows a public key for 
the authority, with only the authority knowing the corresponding private key. The 
following steps (matched by number to Figure 14.11) occur. 


1. A sends a timestamped message to the public-key authority containing a 
request for the current public key of B. 


2. The authority responds with a message that is encrypted using the authority’s pri- 
vate key, PRaytn- Thus, A is able to decrypt the message using the authority’s pub- 
lic key. Therefore, A is assured that the message originated with the authority. The 
message includes the following: 


e B’s public key, PU,, which A can use to encrypt messages destined for B 


e The original request used to enable A to match this response with the cor- 
responding earlier request and to verify that the original request was not 
altered before reception by the authority 
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Figure 14.11 Public-Key Distribution Scenario 


e The original timestamp given so A can determine that this is not an old mes- 
sage from the authority containing a key other than B’s current public key 
3. A stores B’s public key and also uses it to encrypt a message to B containing an 
identifier of A (ID ,) and a nonce (Nj), which is used to identify this transaction 
uniquely. 


> 
mn 


. B retrieves A’s public key from the authority in the same manner as A 
retrieved B’s public key. 


At this point, public keys have been securely delivered to A and B, and they 
may begin their protected exchange. However, two additional steps are desirable: 


6. B sends a message to A encrypted with PU, and containing A’s nonce (N;) as 
well as a new nonce generated by B(N,). Because only B could have 
decrypted message (3), the presence of N, in message (6) assures A that the 
correspondent is B. 


7. A returns N>, which is encrypted using B’s public key, to assure B that its cor- 
respondent is A. 


Thus, a total of seven messages are required. However, the initial four mes- 
sages need be used only infrequently because both A and B can save the other’s 
public key for future use—a technique known as caching. Periodically, a user should 
request fresh copies of the public keys of its correspondents to ensure currency. 


Public-Key Certificates 


The scenario of Figure 14.11 is attractive, yet it has some drawbacks. The public-key 
authority could be somewhat of a bottleneck in the system, for a user must appeal to 
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the authority for a public key for every other user that it wishes to contact. As 
before, the directory of names and public keys maintained by the authority is vul- 
nerable to tampering. 

An alternative approach, first suggested by Kohnfelder [KOHN/78], is to use 
certificates that can be used by participants to exchange keys without contacting a 
public-key authority, in a way that is as reliable as if the keys were obtained 
directly from a public-key authority. In essence, a certificate consists of a public 
Key, an identifier of the key owner, and the whole block signed by a trusted third 
party. Typically, the third party is a certificate authority, such as a government 
agency or a financial institution, that is trusted by the user community. A user can 
present his or her public key to the authority in a secure manner and obtain a cer- 
tificate. The user can then publish the certificate. Anyone needing this user’s pub- 
lic key can obtain the certificate and verify that it is valid by way of the attached 
trusted signature. A participant can also convey its key information to another by 
transmitting its certificate. Other participants can verify that the certificate was 
created by the authority. We can place the following requirements on this scheme: 


1. Any participant can read a certificate to determine the name and public key of 
the certificate’s owner. 


nN 


. Any participant can verify that the certificate originated from the certificate 
authority and is not counterfeit. 


1) 


. Only the certificate authority can create and update certificates. 


These requirements are satisfied by the original proposal in [KOHN78]. Denning 
[DENN83] added the following additional requirement: 


4. Any participant can verify the currency of the certificate. 


A certificate scheme is illustrated in Figure 14.12. Each participant applies to 
the certificate authority, supplying a public key and requesting a certificate. 
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Figure 14.12 Exchange of Public-Key Certificates 
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Application must be in person or by some form of secure authenticated communi- 
cation. For participant A, the authority provides a certificate of the form 


Ca = E(PRoutw [T||ZD.4l|PUs)) 


where PRayn 18 the private key used by the authority and T is a timestamp. A may 
then pass this certificate on to any other participant, who reads and verifies the cer- 
tificate as follows: 


D(PU auth C4) = DUPU sain EOP Ritts [T||1D4]|PU,])) = (7||ZD.4|| PU.) 


The recipient uses the authority’s public key, PU, to decrypt the certifi- 
cate. Because the certificate is readable only using the authority’s public key, this 
verifies that the certificate came from the certificate authority. The elements [D4 
and PU, provide the recipient with the name and public key of the certificate’s 
holder. The timestamp 7 validates the currency of the certificate. The timestamp 
counters the following scenario. A’s private key is learned by an adversary. A gen- 
erates a new private/public key pair and applies to the certificate authority for a 
new certificate. Meanwhile, the adversary replays the old certificate to B. If B then 
encrypts messages using the compromised old public key, the adversary can read 
those messages. 

In this context, the compromise of a private key is comparable to the loss of a 
credit card. The owner cancels the credit card number but is at risk until all possible 
communicants are aware that the old credit card is obsolete. Thus, the timestamp 
serves as something like an expiration date. If a certificate is sufficiently old, it is 
assumed to be expired. 

One scheme has become universally accepted for formatting public-key cer- 
tificates: the X.509 standard. X.509 certificates are used in most network security 
applications, including IP security, transport layer security (TLS), and S/MIME, 
all of which are discussed in Part Five. X.509 is examined in detail in the next 
section. 


14.4 X.509 CERTIFICATES 


ITU-T recommendation X.509 is part of the X.500 series of recommendations that 
define a directory service. The directory is, in effect, a server or distributed set of 
servers that maintains a database of information about users. The information 
includes a mapping from user name to network address, as well as other attributes 
and information about the users. 

X.509 defines a framework for the provision of authentication services by the 
X.500 directory to its users. The directory may serve as a repository of public-key 
certificates of the type discussed in Section 14.3. Each certificate contains the public 
key of a user and is signed with the private key of a trusted certification authority. In 
addition, X.509 defines alternative authentication protocols based on the use of 
public-key certificates. 

X.509 is an important standard because the certificate structure and authenti- 
cation protocols defined in X.509 are used in a variety of contexts. For example, the 
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X.509 certificate format is used in S/MIME (Chapter 18), IP Security (Chapter 19), 
and SSL/TLS (Chapter 16). 

X.509 was initially issued in 1988. The standard was subsequently revised 
to address some of the security concerns documented in [I[ANS90] and 
[MITC90]; a revised recommendation was issued in 1993. A third version was 
issued in 1995 and revised in 2000. 

X.509 is based on the use of public-key cryptography and digital signatures. The 
standard does not dictate the use of a specific algorithm but recommends RSA. The dig- 
ital signature scheme is assumed to require the use of a hash function. Again, the stan- 
dard does not dictate a specific hash algorithm. The 1988 recommendation included the 
description of a recommended hash algorithm; this algorithm has since been shown to 
be insecure and was dropped from the 1993 recommendation. Figure 14.13 illustrates 
the generation of a public-key certificate. 


Certificates 


The heart of the X.509 scheme is the public-key certificate associated with each 
user. These user certificates are assumed to be created by some trusted certifica- 
tion authority (CA) and placed in the directory by the CA or by the user. The 
directory server itself is not responsible for the creation of public keys or for the 
certification function; it merely provides an easily accessible location for users to 
obtain certificates. 

Figure 14.14a shows the general format of a certificate, which includes the fol- 


lowing elements. 
Bob's ID 
information 
Bob's public key 


CA 
information 


Unsigned certificate: 
contains user ID, 
user's public key 


|). -W 


Recipient can verify 
signature by comparing 
hash code values 


Generate hash 
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certificate al 


Signed certificate 
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Create signed Use certificate to 
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Figure 14.13 Public-Key Certificate Use 
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Figure 14.14 X.509 Formats 


All 
versions 


Version: Differentiates among successive versions of the certificate format; the 
default is version 1. If the issuer unique identifier or subject unique identifier 
are present, the value must be version 2. If one or more extensions are present, 
the version must be version 3. 


Serial number: An integer value unique within the issuing CA that is unam- 
biguously associated with this certificate. 


Signature algorithm identifier: The algorithm used to sign the certificate 
together with any associated parameters. Because this information is 
repeated in the signature field at the end of the certificate, this field has little, 
if any, utility. 

Issuer name: X.500 is the name of the CA that created and signed this certificate. 


Period of validity: Consists of two dates: the first and last on which the certifi- 
cate is valid. 


Subject name: The name of the user to whom this certificate refers. That is, this 
certificate certifies the public key of the subject who holds the corresponding 
private key. 


Subject’s public-key information: The public key of the subject, plus an identi- 
fier of the algorithm for which this key is to be used, together with any associ- 
ated parameters. 


Issuer unique identifier: An optional-bit string field used to identify uniquely 
the issuing CA in the event the X.500 name has been reused for different entities. 
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e Subject unique identifier: An optional-bit string field used to identify uniquely 
the subject in the event the X.500 name has been reused for different entities. 


e Extensions: A set of one or more extension fields. Extensions were added in 


version 3 and are discussed later in this section. 


e Signature: Covers all of the other fields of the certificate; it contains the hash 
code of the other fields encrypted with the CA’s private key. This field includes 


the signature algorithm identifier. 


The unique identifier fields were added in version 2 to handle the possible 


reuse of subject and/or issuer names over time. These fields are rarely used. 
The standard uses the following notation to define a certificate: 


CA<A>> = CA {V, SN, AI, CA, UCA, A, UA, Ap, T4} 
where 


Y<X>> = the certificate of user X issued by certification authority Y 


Y {I} = the signing of I by Y. It consists of I with an encrypted hash 
code appended 
= version of the certificate 
SN = serial number of the certificate 
AI = identifier of the algorithm used to sign the certificate 
CA = name of certificate authority 
UCA = optional unique identifier of the CA 
= name of user A 
UA = optional unique identifier of the user A 
Ap = public key of user A 
T“ = period of validity of the certificate 


The CA signs the certificate with its private key. If the corresponding public 
key is known to a user, then that user can verify that a certificate signed by the CA 


is valid. This is the typical digital signature approach illustrated in Figure 13.2. 


OBTAINING A USER’S CERTIFICATE User certificates generated by a CA have the 


following characteristics: 


e Any user with access to the public key of the CA can verify the user public key 


that was certified. 


e No party other than the certification authority can modify the certificate with- 


out this being detected. 


Because certificates are unforgeable, they can be placed in a directory without the 


need for the directory to make special efforts to protect them. 


If all users subscribe to the same CA, then there is a common trust of that CA. 
All user certificates can be placed in the directory for access by all users. In addition, 
a user can transmit his or her certificate directly to other users. In either case, once 
B is in possession of A’s certificate, B has confidence that messages it encrypts with 
A’s public key will be secure from eavesdropping and that messages signed with A’s 


private key are unforgeable. 
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If there is a large community of users, it may not be practical for all users to 
subscribe to the same CA. Because it is the CA that signs certificates, each par- 
ticipating user must have a copy of the CA’s own public key to verify signatures. 
This public key must be provided to each user in an absolutely secure (with 
respect to integrity and authenticity) way so that the user has confidence in the 
associated certificates. Thus, with many users, it may be more practical for there 
to be a number of CAs, each of which securely provides its public key to some 
fraction of the users. 

Now suppose that A has obtained a certificate from certification authority X; 
and B has obtained a certificate from CA X). If A does not securely know the pub- 
lic key of X5, then B’s certificate, issued by X, is useless to A.A can read B’s certifi- 
cate, but A cannot verify the signature. However, if the two CAs have securely 
exchanged their own public keys, the following procedure will enable A to obtain 
B’s public key. 


Step 1 A obtains from the directory the certificate of X, signed by X;. Because A 
securely knows X,’s public key, A can obtain X,’s public key from its cer- 
tificate and verify it by means of X,’s signature on the certificate. 


Step 2 A then goes back to the directory and obtains the certificate of B signed by 
X». Because A now has a trusted copy of X»’s public key, A can verify the 
signature and securely obtain B’s public key. 


A has used a chain of certificates to obtain B’s public key. In the notation of 
X.509, this chain is expressed as 


XK XX <<BS 
In the same fashion, B can obtain A’s public key with the reverse chain: 
XK Ky xX <A> 


This scheme need not be limited to a chain of two certificates. An arbitrarily 
long path of CAs can be followed to produce a chain. A chain with N elements 
would be expressed as 


XK XX KK... XK BS 


In this case, each pair of CAs in the chain (X;, X;4,) must have created certifi- 
cates for each other. 

All these certificates of CAs by CAs need to appear in the directory, and the 
user needs to know how they are linked to follow a path to another user’s public- 
key certificate. X.509 suggests that CAs be arranged in a hierarchy so that naviga- 
tion is straightforward. 

Figure 14.15, taken from X.509, is an example of such a hierarchy. The con- 
nected circles indicate the hierarchical relationship among the CAs; the associated 
boxes indicate certificates maintained in the directory for each CA entry. The direc- 
tory entry for each CA includes two types of certificates: 


e Forward certificates: Certificates of X generated by other CAs 


e Reverse certificates: Certificates generated by X that are the certificates of 
other CAs 
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V<<W>> V<<Y>> 
W<<V>> Y<<V>> 


W<<X>> Y<<Z>> 
X<<W>> Z<<Y>> 
X<<Z>> LEK 


X<<C>> X<<A>> Z<<B>> 


Figure 14.15 X.509 Hierarchy: A Hypothetical Example 


In this example, user A can acquire the following certificates from the direc- 
tory to establish a certification path to B: 


X<K<KWLEW KV V KY Y KLZS ZL <B> 


When A has obtained these certificates, it can unwrap the certification path in 
sequence to recover a trusted copy of B’s public key. Using this public key, A can 
send encrypted messages to B. If A wishes to receive encrypted messages back from 
B, or to sign messages sent to B, then B will require A’s public key, which can be 
obtained from the following certification path: 


ZKYOY <KVSEV KW ww «<K<X>S K <A> 


B can obtain this set of certificates from the directory, or A can provide them 
as part of its initial message to B. 


REVOCATION OF CERTIFICATES Recall from Figure 14.14 that each certificate 
includes a period of validity, much like a credit card. Typically, a new certificate is 
issued just before the expiration of the old one. In addition, it may be desirable 
on occasion to revoke a certificate before it expires, for one of the following 
reasons. 
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1. The user’s private key is assumed to be compromised. 
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. The user is no longer certified by this CA. Reasons for this include that the sub- 
ject’s name has changed, the certificate is superseded, or the certificate was not 
issued in conformance with the CA’s policies. 


3. The CA’s certificate is assumed to be compromised. 


Each CA must maintain a list consisting of all revoked but not expired certifi- 
cates issued by that CA, including both those issued to users and to other CAs. 
These lists should also be posted on the directory. 

Each certificate revocation list (CRL) posted to the directory is signed by the 
issuer and includes (Figure 14.14b) the issuer’s name, the date the list was created, 
the date the next CRL is scheduled to be issued, and an entry for each revoked cer- 
tificate. Each entry consists of the serial number of a certificate and revocation date 
for that certificate. Because serial numbers are unique within a CA, the serial num- 
ber is sufficient to identify the certificate. 

When a user receives a certificate in a message, the user must determine 
whether the certificate has been revoked. The user could check the directory each 
time a certificate is received. To avoid the delays (and possible costs) associated with 
directory searches, it is likely that the user would maintain a local cache of certifi- 
cates and lists of revoked certificates. 


X.509 Version 3 


The X.509 version 2 format does not convey all of the information that recent 
design and implementation experience has shown to be needed. [FORD95] lists the 
following requirements not satisfied by version 2. 


1. The subject field is inadequate to convey the identity of a key owner to a 
public-key user. X.509 names may be relatively short and lacking in obvious 
identification details that may be needed by the user. 


N 


. The subject field is also inadequate for many applications, which typically recog- 
nize entities by an Internet e-mail address, a URL, or some other Internet-related 
identification. 


3. There is a need to indicate security policy information. This enables a security 
application or function, such as IPSec, to relate an X.509 certificate to a given 
policy. 

4. There is a need to limit the damage that can result from a faulty or malicious CA 
by setting constraints on the applicability of a particular certificate. 


Nn 


It is important to be able to identify different keys used by the same owner at 
different times. This feature supports key lifecycle management: in particular, 
the ability to update key pairs for users and CAs on a regular basis or under 
exceptional circumstances. 


Rather than continue to add fields to a fixed format, standards developers felt 
that a more flexible approach was needed. Thus, version 3 includes a number of 
optional extensions that may be added to the version 2 format. Each extension consists 
of an extension identifier, a criticality indicator, and an extension value. The criticality 
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indicator indicates whether an extension can be safely ignored. If the indicator has a 
value of TRUE and an implementation does not recognize the extension, it must treat 
the certificate as invalid. 

The certificate extensions fall into three main categories: key and policy infor- 
mation, subject and issuer attributes, and certification path constraints. 


Key AND Poticy INFORMATION These extensions convey additional information 
about the subject and issuer keys, plus indicators of certificate policy. A certificate 
policy is a named set of rules that indicates the applicability of a certificate to a 
particular community and/or class of application with common security 
requirements. For example, a policy might be applicable to the authentication of 
electronic data interchange (EDI) transactions for the trading of goods within a 
given price range. 
This area includes: 


e Authority key identifier: Identifies the public key to be used to verify the 
signature on this certificate or CRL. Enables distinct keys of the same 
CA to be differentiated. One use of this field is to handle CA key pair 
updating. 

e Subject key identifier: Identifies the public key being certified. Useful for sub- 
ject key pair updating. Also, a subject may have multiple key pairs and, corre- 
spondingly, different certificates for different purposes (e.g., digital signature 
and encryption key agreement). 


e Key usage: Indicates a restriction imposed as to the purposes for which, and 
the policies under which, the certified public key may be used. May indicate 
one or more of the following: digital signature, nonrepudiation, key encryp- 
tion, data encryption, key agreement, CA signature verification on certificates, 
CA signature verification on CRLs. 


e Private-key usage period: Indicates the period of use of the private key corre- 
sponding to the public key. Typically, the private key is used over a different 
period from the validity of the public key. For example, with digital signature 
keys, the usage period for the signing private key is typically shorter than that 
for the verifying public key. 


¢ Certificate policies: Certificates may be used in environments where multiple 
policies apply. This extension lists policies that the certificate is recognized as 
supporting, together with optional qualifier information. 


e Policy mappings: Used only in certificates for CAs issued by other CAs. Policy 
mappings allow an issuing CA to indicate that one or more of that issuer’s 
policies can be considered equivalent to another policy used in the subject 
CA’s domain. 


CERTIFICATE SUBJECT AND ISSUER ATTRIBUTES These extensions support alternative 
names, in alternative formats, for a certificate subject or certificate issuer and can 
convey additional information about the certificate subject to increase a certificate 
user’s confidence that the certificate subject is a particular person or entity. For 
example, information such as postal address, position within a corporation, or 
picture image may be required. 


14.5 / PUBLIC-KEY INFRASTRUCTURE 437 


The extension fields in this area include: 


e 


Subject alternative name: Contains one or more alternative names, using any 
of a variety of forms. This field is important for supporting certain applications, 
such as electronic mail, EDI, and IPSec, which may employ their own name 
forms. 


Issuer alternative name: Contains one or more alternative names, using any of 
a variety of forms. 


e Subject directory attributes: Conveys any desired X.500 directory attribute 
values for the subject of this certificate. 


CERTIFICATION PATH CONSTRAINTS These extensions allow constraint specifications 
to be included in certificates issued for CAs by other CAs. The constraints may 
restrict the types of certificates that can be issued by the subject CA or that may 
occur subsequently in a certification chain. 

The extension fields in this area include: 


e Basic constraints: Indicates if the subject may act as a CA. If so, a certification 
path length constraint may be specified. 


e Name constraints: Indicates a name space within which all subject names in 
subsequent certificates in a certification path must be located. 


e Policy constraints: Specifies constraints that may require explicit certificate 
policy identification or inhibit policy mapping for the remainder of the certifi- 
cation path. 


14.5 PUBLIC-KEY INFRASTRUCTURE 


RFC 2822 (Internet Security Glossary) defines public-key infrastructure (PKI) as 
the set of hardware, software, people, policies, and procedures needed to create, 
manage, store, distribute, and revoke digital certificates based on asymmetric cryp- 
tography. The principal objective for developing a PKI is to enable secure, conve- 
nient, and efficient acquisition of public keys. The Internet Engineering Task Force 
(IETF) Public Key Infrastructure X.509 (PKIX) working group has been the dri- 
ving force behind setting up a formal (and generic) model based on X.509 that is 
suitable for deploying a certificate-based architecture on the Internet. This section 
describes the PKIX model. 

Figure 14.16 shows the interrelationship among the key elements of the PKIX 
model. These elements are 


e End entity: A generic term used to denote end users, devices (e.g., servers, 
routers), or any other entity that can be identified in the subject field of a pub- 
lic key certificate. End entities typically consume and/or support PKI-related 
services. 


Certification authority (CA): The issuer of certificates and (usually) certificate 
revocation lists (CRLs). It may also support a variety of administrative 
functions, although these are often delegated to one or more Registration 
Authorities. 


438 


Certificate/CRL retrieval ; 
End entity 
Registration, 
initialization, 
certification, 
Registration 
authority 


key pair recovery, 
key pair update 
revocation request 


publication 


Certificate/CRL Repository 


Certificate/CRL 
publication Certificate 
authority 
Cross 
CRL certification 
publication 


Certificate 
authority 


PKI 
management 
entities 


4.16 PKIX Architectural Model 


e Registration authority (RA): An optional component that can assume a num- 


ber of administrative functions from the CA. The RA is often associated with the 
end entity registration process but can assist in a number of other areas as well. 


CRL issuer: An optional component that a CA can delegate to publish CRLs. 


Repository: A generic term used to denote any method for storing certificates 
and CRLs so that they can be retrieved by end entities. 


KIX 


PKIX identifies a number of management functions that potentially need to be sup- 
ported by management protocols. These are indicated in Figure 14.16 and include 
the following: 


Registration: This is the process whereby a user first makes itself known to a 
CA (directly or through an RA), prior to that CA issuing a certificate or cer- 
tificates for that user. Registration begins the process of enrolling in a PKI. 
Registration usually involves some offline or online procedure for mutual 
authentication. Typically, the end entity is issued one or more shared secret 
keys used for subsequent authentication. 


Initialization: Before a client system can operate securely, it is necessary to 
install key materials that have the appropriate relationship with keys stored 


14.6 / RECOMMENDED READING AND WEB SITES 439 


elsewhere in the infrastructure. For example, the client needs to be securely 
initialized with the public key and other assured information of the trusted 
CA(s), to be used in validating certificate paths. 


¢ Certification: This is the process in which a CA issues a certificate for a user’s 
public key, returns that certificate to the user’s client system, and/or posts that 
certificate in a repository. 


e Key pair recovery: Key pairs can be used to support digital signature creation 
and verification, encryption and decryption, or both. When a key pair is used for 
encryption/decryption, it is important to provide a mechanism to recover the nec- 
essary decryption keys when normal access to the keying material is no longer 
possible, otherwise it will not be possible to recover the encrypted data. Loss of 
access to the decryption key can result from forgotten passwords/PINs, corrupted 
disk drives, damage to hardware tokens, and so on. Key pair recovery allows end 
entities to restore their encryption/decryption key pair from an authorized key 
backup facility (typically, the CA that issued the end entity’s certificate). 


¢ Key pair update: All key pairs need to be updated regularly (i.e., replaced with 
a new key pair) and new certificates issued. Update is required when the cer- 
tificate lifetime expires and as a result of certificate revocation. 


e Revocation request: An authorized person advises a CA of an abnormal situa- 
tion requiring certificate revocation. Reasons for revocation include private- 
key compromise, change in affiliation, and name change. 


¢ Cross certification: Two CAs exchange information used in establishing a 
cross-certificate. A cross-certificate is a certificate issued by one CA to another 
CA that contains a CA signature key used for issuing certificates. 


PKIX Management Protocols 


The PKIX working group has defines two alternative management protocols 
between PKIX entities that support the management functions listed in the preced- 
ing subsection. RFC 2510 defines the certificate management protocols (CMP). 
Within CMP, each of the management functions is explicitly identified by specific 
protocol exchanges. CMP is designed to be a flexible protocol able to accommodate 
a variety of technical, operational, and business models. 

RFC 2797 defines certificate management messages over CMS (CMC), where 
CMS refers to RFC 2630, cryptographic message syntax. CMC is built on earlier work 
and is intended to leverage existing implementations. Although all of the PKIX func- 
tions are supported, the functions do not all map into specific protocol exchanges. 


14.6 RECOMMENDED READING AND WEB SITES 


An exhaustive and essential resource on the topics of this chapter is the three-volume NIST SP800- 
57 [BARK07b. BARKO7c, BARKO8]. [FUMY93] is a good survey of key management principles. 
Another interesting survey, which looks at many key management techniques, is [HEGLO6]. 

[PERL99] reviews various trust models that can be used in a PKI. [GUTM02] high- 
lights difficulties in PKI use and recommends approaches for an effective PKI. 
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BARK07b Barker, E., et al. Recommendation for Key Management—Part 1: General. 
NIST SP800-57, March 2007. 


BARKO07c Barker, E., et al. Recommendation for Key Management—Part 2: Best Practices 
for Key Management Organization. NIST SP800-57, March 2007. 


BARKO08 Barker, E., et al. Recommendation for Key Management—Part 3: Specific Key 
Management Guidance. NIST SP800-57, August 2008. 
FUMY93 Fumy, S., and Landrock, P. “Principles of Key Management.” JEEE Journal on 


Selected Areas in Communications, June 1993. 

GUTM02 Gutmann, P. “PKI: It’s Not Dead, Just Resting.” Computer, August 2002. 

HEGLO06 Hegland, A., et al. “A Survey of Key Management in Ad Hoc Networks.” JEEE 
Communications Surveys & Tutorials. 3"! Quarter 2006. 

PERL99 Perlman, R. “An Overview of PKI Trust Models.” JEEE Network, November/ 
December 1999. 


Recommended Web Sites: 


e Public-Key Infrastructure Working Group: IETF group developing standards based on 
X.509v3. 


e Verisign: A leading commercial vendor of X.509-related products; white papers and 
other worthwhile material at this site. 


e NIST PKI Program: Good source of information. 


14.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


end-to-end encryption man-the-middle attack public-key certificate 
key distribution master key public-key directory 


key distribution center (KDC) nonce X.509 certificate 
key management 


Review Questions 


14.1 List ways in which secret keys can be distributed to two communicating parties. 

14.2 What is the difference between a session key and a master key? 

14.3. What is a nonce? 

14.4 What is a key distribution center? 

14.5 What are two different uses of public-key cryptography related to key distribution? 
14.6 List four general categories of schemes for the distribution of public keys. 

14.7 What are the essential ingredients of a public-key directory? 
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Key ' 
Distribution 
‘Center (KDC) 


(2) IDa, E(Kg, Ng), Dp, E(Kp, Np) 


(3) E(Kp, [Ks, IDq, Np]), E(Ka, [Ks, Dp, Nal) 


FP E(K,, [Ky, IDp, oo 


(1) A, E(Ka, Na) 


Figure 14.17 Figure for Problem 14.1 


14.8 What is a public-key certificate? 
14.9 What are the requirements for the use of a public-key certificate scheme? 
14.10 What is the purpose of the X.509 standard? 
14.11 What is a chain of certificates? 
14.12 Howis an X.509 certificate revoked? 
Problems 
14.1 One local area network vendor provides a key distribution facility, as illustrated in 
Figure 14.17. 
a. Describe the scheme. 
b. Compare this scheme to that of Figure 14.3. What are the pros and cons? 
14.2 “We are under great pressure, Holmes.” Detective Lestrade looked nervous. “We 


have learned that copies of sensitive government documents are stored in computers 
of one foreign embassy here in London. Normally these documents exist in electronic 
form only on a selected few government computers that satisfy the most stringent 
security requirements. However, sometimes they must be sent through the network 
connecting all government computers. But all messages in this network are encrypted 
using a top-secret encryption algorithm certified by our best crypto experts. Even the 
NSA and the KGB are unable to break it. And now these documents have appeared 
in hands of diplomats of a small, otherwise insignificant, country. And we have no idea 
how it could happen.” 


“But you do have some suspicion who did it, do you?” asked Holmes. 


“Yes, we did some routine investigation. There is a man who has legal access to 
one of the government computers and has frequent contacts with diplomats from the 
embassy. But the computer he has access to is not one of the trusted ones where these 
documents are normally stored. He is the suspect, but we have no idea how he could 
obtain copies of the documents. Even if he could obtain a copy of an encrypted docu- 
ment, he couldn’t decrypt it.” 
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14.4 


14.5 


“Hmm, please describe the communication protocol used on the network.” 
Holmes opened his eyes, thus proving that he had followed Lestrade’s talk with an 
attention that contrasted with his sleepy look. 

“Well, the protocol is as follows. Each node N of the network has been assigned 
a unique secret key K,,. This key is used to secure communication between the node 
and a trusted server. That is, all the keys are stored also on the server. User A, wishing 
to send a secret message M to user B, initiates the following protocol: 


1. A generates a random number R and sends to the server his name A, destination 
B, and E(K,, R). 

Server responds by sending E(K,, R) to A. 

A sends E(R, M) together with E(K,, R) to B. 

B knows K,, thus decrypts E(K,, R), to get R and will subsequently use R to 
decrypt E(R, M) to get M. 


BY 


You see that a random key is generated every time a message has to be sent. I admit 
the man could intercept messages sent between the top-secret trusted nodes, but I see 
no way he could decrypt them.” 

“Well, I think you have your man, Lestrade. The protocol isn’t secure because 
the server doesn’t authenticate users who send him a request. Apparently designers 
of the protocol have believed that sending E(K,, R) implicitly authenticates user X as 
the sender, as only X (and the server) knows K,. But you know that E(K,, R) can be 
intercepted and later replayed. Once you understand where the hole is, you will be 
able to obtain enough evidence by monitoring the man’s use of the computer he has 
access to. Most likely he works as follows. After intercepting E(K,, R) and E(R, M) 
(see steps 1 and 3 of the protocol), the man, let’s denote him as Z, will continue by 
pretending to be A and... 

Finish the sentence for Holmes. 

The 1988 version of X.509 lists properties that RSA keys must satisfy to be secure 
given current knowledge about the difficulty of factoring large numbers. The discus- 
sion concludes with a constraint on the public exponent and the modulus n: 


It must be ensured that e > log,(m) to prevent attack by taking the eth root 
mod v to disclose the plaintext. 


Although the constraint is correct, the reason given for requiring it is incorrect. What 
is wrong with the reason given and what is the correct reason? 


Find at least one intermediate certification authority’s certificate and one trusted root 
certification authority’s certificate on your computer (e.g. in the browser). Print 
screenshots of both the general and details tab for each certificate. 


NIST defines the term cryptoperiod as the time span during which a specific key is 
authorized for use or in which the keys for a given system or application may remain 
in effect. One document on key management uses the following time diagram for a 
shared secret key. 


Originator Usage Period 
—— =| 


Recipient Usage Period 
<—————_annnnnnnnnnnnnnnEnEEEN ad 


Cryptoperiod 


14.6 


14.7 
14.8 
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Explain the overlap by giving an example application in which the originator’s usage 
period for the shared secret key begins before the recipient’s usage period and also 
ends before the recipients usage period. 


Consider the following protocol, designed to let A and B decide on a fresh, shared 

session key K',z. We assume that they already share a long-term key K yz. 

1. A>B:A, Nag. 

2. B— A:E(Kap, [Na, Kis) 

3. A— B:E(K'yp, Na) 

a. We first try to understand the protocol designer’s reasoning: 

—Why would A and B believe after the protocol ran that they share K),, with the 
other party? 

—wWhy would they believe that this shared key is fresh? 

In both cases, you should explain both the reasons of both A and B, so your 
answer should complete the sentences 

A believes that she shares K’,, with B since... 

B believes that he shares K’,, with A since... 

A believes that K’,, is fresh since... 

B believes that K’,, is fresh since... 

b. Assume now that A starts a run of this protocol with B. However, the connection 
is intercepted by the adversary C. Show how C can start a new run of the protocol 
using reflection, causing A to believe that she has agreed on a fresh key with B (in 
spite of the fact that she has only been communicating with C). Thus, in particular, 
the belief in (a) is false. 

c. Propose a modification of the protocol that prevents this attack. 


What are the core components of a PKI? Briefly describe each component. 
Explain the problems with key management and how it affects symmetric cryptography. 


Note: The remaining problems deal with the a cryptographic product developed by IBM, 
which is briefly described in a document at this book’s Web site (IBMCrypto.pdf). Try these 
problems after reviewing the document. 


14.9 


14.10 


14.11 


What is the effect of adding the instruction EMKi 
EMK;: X > E(KMH;,X) i = 0,1 


Suppose N different systems use the IBM Cryptographic Subsystem with host master 
keys KMH[i](i = 1, 2,...N). Devise a method for communicating between systems 
without requiring the system to either share a common host master key or to divulge 
their individual host master keys. Hint: each system needs three variants of its host 
master key. 

The principal objective of the IBM Cryptographic Subsystem is to protect transmis- 
sions between a terminal and the processing system. Devise a procedure, perhaps 
adding instructions, which will allow the processor to generate a session key KS and 
distribute it to Terminal i and Terminal j without having to store a key-equivalent 
variable in the host. 
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We cannot enter into alliance with neighboring princes until we are acquainted 
with their designs. 


—The Art of War, Sun Tzu 


KEY POINTS 


© Mutual authentication protocols enable communicating parties to satisfy 
themselves mutually about each other’s identity and to exchange session 
keys. 

® Kerberos is an authentication service designed for use in a distributed 
environment. 

® Kerberos provides a trusted third-party authentication service that enables 
clients and servers to establish authenticated communication. 

© Identity management is a centralized, automated approach to provide 
enterprise-wide access to resources by employees and other authorized 
individuals. 

® Identity federation is, in essence, an extension of identity management to 
multiple security domains. 


This chapter examines some of the authentication functions that have been developed 
to support network-based use authentication. The chapter begins with an introduction 
to some of the concepts and key considerations for user authentication over a network 
or the Internet. The next section examines user-authentication protocols that rely on 
symmetric encryption. This is followed by a section on one of the earliest and also one 
of the most widely used authentication services: Kerberos. Next, the chapter looks at 
user-authentication protocols that rely on asymmetric encryption. This is followed by a 
discussion of the X.509 user-authentication protocol. Finally, the concept of federated 
identity is introduced. 


15.1 REMOTE USER-AUTHENTICATION PRINCIPLES 


In most computer security contexts, user authentication is the fundamental building 
block and the primary line of defense. User authentication is the basis for most 
types of access control and for user accountability. RFC 2828 defines user authenti- 
cation as shown on the following page. 

For example, user Alice Toklas could have the user identifier ABTOKLAS. 
This information needs to be stored on any server or computer system that Alice 
wishes to use and could be known to system administrators and other users. A typi- 
cal item of authentication information associated with this user ID is a password, 
which is kept secret (known only to Alice and to the system). If no one is able to 
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The process of verifying an identity claimed by or for a system entity. An 
authentication process consists of two steps: 


° Identification step: Presenting an identifier to the security system. 


(Identifiers should be assigned carefully, because authenticated identities 
are the basis for other security services, such as access control service.) 


© Verification step: Presenting or generating authentication information that 
corroborates the binding between the entity and the identifier. 


obtain or guess Alice’s password, then the combination of Alice’s user ID and 
password enables administrators to set up Alice’s access permissions and audit her 
activity. Because Alice’s ID is not secret, system users can send her e-mail, but 
because her password is secret, no one can pretend to be Alice. 

In essence, identification is the means by which a user provides a claimed iden- 
tity to the system; user authentication is the means of establishing the validity of the 
claim. Note that user authentication is distinct from message authentication. As 
defined in Chapter 12, message authentication is a procedure that allows communi- 
cating parties to verify that the contents of a received message have not been 
altered and that the source is authentic. This chapter is concerned solely with user 
authentication. 

There are four general means of authenticating a user’s identity, which can be 
used alone or in combination: 


e Something the individual knows: Examples include a password, a 
personal identification number (PIN), or answers to a prearranged set of 
questions. 


e Something the individual possesses: Examples include cryptographic keys, 
electronic keycards, smart cards, and physical keys. This type of authenticator 
is referred to as a token. 


e Something the individual is (static biometrics): Examples include recognition 
by fingerprint, retina, and face. 


e Something the individual does (dynamic biometrics): Examples include recog- 
nition by voice pattern, handwriting characteristics, and typing rhythm. 


All of these methods, properly implemented and used, can provide secure user 
authentication. However, each method has problems. An adversary may be able to 
guess or steal a password. Similarly, an adversary may be able to forge or steal a 
token. A user may forget a password or lose a token. Furthermore, there is a signifi- 
cant administrative overhead for managing password and token information on 
systems and securing such information on systems. With respect to biometric 
authenticators, there are a variety of problems, including dealing with false positives 
and false negatives, user acceptance, cost, and convenience. For network-based user 
authentication, the most important methods involve cryptographic keys and some- 
thing the individual knows, such as a password. 
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Mutual Authentication 


An important application area is that of mutual authentication protocols. Such 
protocols enable communicating parties to satisfy themselves mutually about each 
other’s identity and to exchange session keys. This topic was examined in Chapter 14. 
There, the focus was key distribution. We return to this topic here to consider the 
wider implications of authentication. 

Central to the problem of authenticated key exchange are two issues: confiden- 
tiality and timeliness. To prevent masquerade and to prevent compromise of session 
keys, essential identification and session-key information must be communicated in 
encrypted form. This requires the prior existence of secret or public keys that can be 
used for this purpose. The second issue, timeliness, is important because of the threat of 
message replays. Such replays, at worst, could allow an opponent to compromise a ses- 
sion key or successfully impersonate another party. At minimum, a successful replay can 
disrupt operations by presenting parties with messages that appear genuine but are not. 

[GONG93] lists the following examples of replay attacks: 


e Simple replay: The opponent simply copies a message and replays it later. 


e Repetition that can be logged: An opponent can replay a timestamped message 
within the valid time window. 


e Repetition that cannot be detected: This situation could arise because the 
original message could have been suppressed and thus did not arrive at its 
destination; only the replay message arrives. 


e Backward replay without modification: This is a replay back to the message 
sender. This attack is possible if symmetric encryption is used and the sender 
cannot easily recognize the difference between messages sent and messages 
received on the basis of content. 


One approach to coping with replay attacks is to attach a sequence number to 
each message used in an authentication exchange. A new message is accepted only if 
its sequence number is in the proper order. The difficulty with this approach is that 
it requires each party to keep track of the last sequence number for each claimant it 
has dealt with. Because of this overhead, sequence numbers are generally not used 
for authentication and key exchange. Instead, one of the following two general 
approaches is used: 


e Timestamps: Party A accepts a message as fresh only if the message contains a 
timestamp that, in A’s judgment, is close enough to A’s knowledge of current 
time. This approach requires that clocks among the various participants be 
synchronized. 


e Challenge/response: Party A, expecting a fresh message from B, first sends B a 
nonce (challenge) and requires that the subsequent message (response) 
received from B contain the correct nonce value. 


It can be argued (e.g., [LAM92a]) that the timestamp approach should not be 
used for connection-oriented applications because of the inherent difficulties with 
this technique. First, some sort of protocol is needed to maintain synchronization 
among the various processor clocks. This protocol must be both fault tolerant, to 
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cope with network errors, and secure, to cope with hostile attacks. Second, the oppor- 
tunity for a successful attack will arise if there is a temporary loss of synchronization 
resulting from a fault in the clock mechanism of one of the parties. Finally, because of 
the variable and unpredictable nature of network delays, distributed clocks cannot 
be expected to maintain precise synchronization. Therefore, any timestamp-based 
procedure must allow for a window of time sufficiently large to accommodate net- 
work delays yet sufficiently small to minimize the opportunity for attack. 

On the other hand, the challenge-response approach is unsuitable for a con- 
nectionless type of application, because it requires the overhead of a handshake 
before any connectionless transmission, effectively negating the chief characteristic 
of a connectionless transaction. For such applications, reliance on some sort of 
secure time server and a consistent attempt by each party to keep its clocks in syn- 
chronization may be the best approach (e.g., [LAM92b]). 


One-Way Authentication 


One application for which encryption is growing in popularity is electronic mail 
(e-mail). The very nature of electronic mail, and its chief benefit, is that it is not 
necessary for the sender and receiver to be online at the same time. Instead, the 
e-mail message is forwarded to the receiver’s electronic mailbox, where it is 
buffered until the receiver is available to read it. 

The “envelope” or header of the e-mail message must be in the clear, so that 
the message can be handled by the store-and-forward e-mail protocol, such as the 
Simple Mail Transfer Protocol (SMTP) or X.400. However, it is often desirable that 
the mail-handling protocol not require access to the plaintext form of the message, 
because that would require trusting the mail-handling mechanism. Accordingly, the 
e-mail message should be encrypted such that the mail-handling system is not in 
possession of the decryption key. 

A second requirement is that of authentication. Typically, the recipient wants 
some assurance that the message is from the alleged sender. 


15.2 REMOTE USER-AUTHENTICATION USING 


SYMMETRIC ENCRYPTION 


Mutual Authentication 


As was discussed in Chapter 14, a two-level hierarchy of symmetric encryption keys 
can be used to provide confidentiality for communication in a distributed environ- 
ment. In general, this strategy involves the use of a trusted key distribution center 
(KDC). Each party in the network shares a secret key, known as a master key, with 
the KDC. The KDC is responsible for generating keys to be used for a short time 
over a connection between two parties, known as session keys, and for distributing 
those keys using the master keys to protect the distribution. This approach is quite 
common. As an example, we look at the Kerberos system in Section 15.3. The 
discussion in this subsection is relevant to an understanding of the Kerberos 
mechanisms. 

Figure 14.3 illustrates a proposal initially put forth by Needham and 
Schroeder [NEED78] for secret key distribution using a KDC that, as was 
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mentioned in Chapter 14, includes authentication features. The protocol can be 
summarized as follows.! 


1, A>KDC: ID,||IDg||N, 


2. KDC> A: E(K,, [Ky||Dp||N1 ||E(Ko, [Ks|| 7D.4])) 
3. AB: E(K,, [K,||ZD.4]) 

4. B>A: E(K,, No) 

5. ASB: E(K,, £(N>)) 


Secret keys K, and K, are shared between A and the KDC and B and the 
KDC , respectively. The purpose of the protocol is to distribute securely a session key 
K, to A and B.A securely acquires a new session key in step 2. The message in step 3 
can be decrypted, and hence understood, only by B. Step 4 reflects B’s knowledge of 
K,, and step 5 assures B of A’s knowledge of K, and assures B that this is a fresh mes- 
sage because of the use of the nonce N5. Recall from our discussion in Chapter 14 
that the purpose of steps 4 and 5 is to prevent a certain type of replay attack. In par- 
ticular, if an opponent is able to capture the message in step 3 and replay it, this might 
in some fashion disrupt operations at B. 

Despite the handshake of steps 4 and 5, the protocol is still vulnerable to a form 
of replay attack. Suppose that an opponent, X, has been able to compromise an old ses- 
sion key. Admittedly, this is a much more unlikely occurrence than that an opponent 
has simply observed and recorded step 3. Nevertheless, it is a potential security risk. X 
can impersonate A and trick B into using the old key by simply replaying step 3. Unless 
B remembers indefinitely all previous session keys used with A, B will be unable to 
determine that this is a replay. If X can intercept the handshake message in step 4, then 
it can impersonate A’s response in step 5. From this point on, X can send bogus mes- 
sages to B that appear to B to come from A using an authenticated session key. 

Denning [DENN81, DENN872] proposes to overcome this weakness by a mod- 
ification to the Needham/Schroeder protocol that includes the addition of a time- 
stamp to steps 2 and 3. Her proposal assumes that the master keys, K, and K,, are 
secure, and it consists of the following steps. 


1. A>KDC: ID,|lIDz 


2. KDC>A:  E(K,, [Ks|| ID a||T||E(Ks, [Ksl| Dall 7) 
3. AB: E(K,, [Ks||1D.4]| 7]) 

4. B—> A: E(K,, N;) 

5. AB: E(K,, f(N,)) 


T is a timestamp that assures A and B that the session key has only just been 
generated. Thus, both A and B know that the key distribution is a fresh exchange. A 
and B can verify timeliness by checking that 


|Clock — T| < At, + At, 


where Az, is the estimated normal discrepancy between the KDC’s clock and the local 
clock (at A or B) and At is the expected network delay time. Each node can set its 


'The portion to the left of the colon indicates the sender and receiver; the portion to the right indicates 
the contents of the message; the symbol || indicates concatenation. 


450 CHAPTER 15 / USER AUTHENTICATION 


clock against some standard reference source. Because the timestamp TJ is encrypted 
using the secure master keys, an opponent, even with knowledge of an old session key, 
cannot succeed because a replay of step 3 will be detected by B as untimely. 

A final point: Steps 4 and 5 were not included in the original presentation 
[DENN81] but were added later [DENN82]. These steps confirm the receipt of the 
session key at B. 

The Denning protocol seems to provide an increased degree of security 
compared to the Needham/Schroeder protocol. However, a new concern is 
raised: namely, that this new scheme requires reliance on clocks that are synchro- 
nized throughout the network. [GONG92] points out a risk involved. The risk is 
based on the fact that the distributed clocks can become unsynchronized as a 
result of sabotage on or faults in the clocks or the synchronization mechanism.” 
The problem occurs when a sender’s clock is ahead of the intended recipient’s 
clock. In this case, an opponent can intercept a message from the sender and 
replay it later when the timestamp in the message becomes current at the recipi- 
ent’s site. This replay could cause unexpected results. Gong refers to such attacks 
as suppress-replay attacks. 

One way to counter suppress-replay attacks is to enforce the requirement that 
parties regularly check their clocks against the KDC’s clock. The other alternative, 
which avoids the need for clock synchronization, is to rely on handshaking protocols 
using nonces. This latter alternative is not vulnerable to a suppress-replay attack, 
because the nonces the recipient will choose in the future are unpredictable to the 
sender. The Needham/Schroeder protocol relies on nonces only but, as we have 
seen, has other vulnerabilities. 

In [KEHN92], an attempt is made to respond to the concerns about suppress- 
replay attacks and at the same time fix the problems in the Needham/Schroeder 
protocol. Subsequently, an inconsistency in this latter protocol was noted and an 
improved strategy was presented in [NEUM93a].° The protocol is 


1. A—B: ID AllN, 

B—KDC:  IDgIINjIIE(Ky, [ID 4||NollTp] ) 

3. KDC>A: E(K;, Da||Na||Ks|| Ts) ||E(Ks, UD all Ksll Ts) IIo 
AB: E(K», [ID, || Ks || Tp] ) || E(Ks, No) 


nN 


> 


Let us follow this exchange step by step. 


1. A initiates the authentication exchange by generating a nonce, N,, and 
sending that plus its identifier to B in plaintext. This nonce will be returned 
to A in an encrypted message that includes the session key, assuring A of its 
timeliness. 


. B alerts the KDC that a session key is needed. Its message to the KDC includes 
its identifier and a nonce, N,,. This nonce will be returned to B in an encrypted 
message that includes the session key, assuring B of its timeliness. B’s message to 


nN 


Such things can and do happen. In recent years, flawed chips were used in a number of computers and 
other electronic systems to track the time and date. The chips had a tendency to skip forward one day. 
[NEUM90]. 


It really is hard to get these things right. 
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the KDC also includes a block encrypted with the secret key shared by B and the 
KDC. This block is used to instruct the KDC to issue credentials to A; the block 
specifies the intended recipient of the credentials, a suggested expiration time for 
the credentials, and the nonce received from A. 


Ge 


. The KDC passes on to A B’s nonce and a block encrypted with the secret key 
that B shares with the KDC. The block serves as a “ticket” that can be used by A 
for subsequent authentications, as will be seen. The KDC also sends to A a block 
encrypted with the secret key shared by A and the KDC. This block verifies that 
B has received A’s initial message (JD g) and that this is a timely message and not 
a replay (N,), and it provides A with a session key (K,) and the time limit on its 
use (7;,). 

4. A transmits the ticket to B, together with the B’s nonce, the latter encrypted 

with the session key. The ticket provides B with the secret key that is used to 

decrypt E(K,, N,) to recover the nonce. The fact that B’s nonce is encrypted 

with the session key authenticates that the message came from A and is not a 

replay. 


This protocol provides an effective, secure means for A and B to establish a 
session with a secure session key. Furthermore, the protocol leaves A in possession 
of a key that can be used for subsequent authentication to B, avoiding the need to 
contact the authentication server repeatedly. Suppose that A and B establish a ses- 
sion using the aforementioned protocol and then conclude that session. 
Subsequently, but within the time limit established by the protocol, A desires a new 
session with B. The following protocol ensues: 


1. AB: E(K;,[ID¢ ||Ks || To]) || No 
2. B>A: N%,|/E(K,, N’,) 
3. A>B: E(K,, N's) 


When B receives the message in step 1, it verifies that the ticket has not expired. The 
newly generated nonces N', and N’, assure each party that there is no replay attack. 

In all the foregoing, the time specified in 7; is a time relative to B’s clock. 
Thus, this timestamp does not require synchronized clocks, because B checks only 
self-generated timestamps. 


One-Way Authentication 


Using symmetric encryption, the decentralized key distribution scenario illustrated 
in Figure 14.5 is impractical. This scheme requires the sender to issue a request to 
the intended recipient, await a response that includes a session key, and only then 
send the message. 

With some refinement, the KDC strategy illustrated in Figure 14.3 is a candi- 
date for encrypted electronic mail. Because we wish to avoid requiring that the 
recipient (B) be on line at the same time as the sender (A), steps 4 and 5 must be 
eliminated. For a message with content M, the sequence is as follows: 


1. A>KDC: ID,|\IIDgIINy 
2. KDC A: E(K,, [Ks||ZDz || Ni |JE(Ks, [Ks||7D4])) 
3. AB: E(K;, [K; || 1D.4]) || E(Ks,/) 
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This approach guarantees that only the intended recipient of a message will be 
able to read it. It also provides a level of authentication that the sender is A. As 
specified, the protocol does not protect against replays. Some measure of defense 
could be provided by including a timestamp with the message. However, because 
of the potential delays in the e-mail process, such timestamps may have limited 
usefulness. 


15.3 KERBEROS 


Kerberos* is an authentication service developed as part of Project Athena at MIT. 
The problem that Kerberos addresses is this: Assume an open distributed environ- 
ment in which users at workstations wish to access services on servers distributed 
throughout the network. We would like for servers to be able to restrict access to 
authorized users and to be able to authenticate requests for service. In this environ- 
ment, a workstation cannot be trusted to identify its users correctly to network ser- 
vices. In particular, the following three threats exist: 


1. A user may gain access to a particular workstation and pretend to be another 
user operating from that workstation. 


2. A user may alter the network address of a workstation so that the requests sent 
from the altered workstation appear to come from the impersonated workstation. 


3. A user may eavesdrop on exchanges and use a replay attack to gain entrance 
to a server or to disrupt operations. 


In any of these cases, an unauthorized user may be able to gain access to services 
and data that he or she is not authorized to access. Rather than building in elabo- 
rate authentication protocols at each server, Kerberos provides a centralized 
authentication server whose function is to authenticate users to servers and 
servers to users. Unlike most other authentication schemes described in this book, 
Kerberos relies exclusively on symmetric encryption, making no use of public-key 
encryption. 

Two versions of Kerberos are in common use. Version 4 [MILL88, STEI88] 
implementations still exist. Version 5 [KOHL94] corrects some of the security 
deficiencies of version 4 and has been issued as a proposed Internet Standard 
(RFC 4120). 

We begin this section with a brief discussion of the motivation for the 
Kerberos approach. Then, because of the complexity of Kerberos, it is best to start 
with a description of the authentication protocol used in version 4. This enables us 
to see the essence of the Kerberos strategy without considering some of the details 
required to handle subtle security threats. Finally, we examine version 5. 


4<Tn Greek mythology, a many headed dog, commonly three, perhaps with a serpent’s tail, the guardian of 
the entrance of Hades.” From Dictionary of Subjects and Symbols in Art, by James Hall, Harper & Row, 
1979. Just as the Greek Kerberos has three heads, the modern Kerberos was intended to have three com- 
ponents to guard a network’s gate: authentication, accounting, and audit. The last two heads were never 
implemented. 

Versions 1 through 3 were internal development versions. Version 4 is the “original” Kerberos. 


15.3 / KERBEROS 453 


Motivation 


If a set of users is provided with dedicated personal computers that have no network 
connections, then a user’s resources and files can be protected by physically securing 
each personal computer. When these users instead are served by a centralized time- 
sharing system, the time-sharing operating system must provide the security. The 
operating system can enforce access-control policies based on user identity and use 
the logon procedure to identify users. 

Today, neither of these scenarios is typical. More common is a distributed archi- 
tecture consisting of dedicated user workstations (clients) and distributed or central- 
ized servers. In this environment, three approaches to security can be envisioned. 


1. Rely on each individual client workstation to assure the identity of its user or 
users and rely on each server to enforce a security policy based on user identi- 
fication (ID). 

. Require that client systems authenticate themselves to servers, but trust the client 
system concerning the identity of its user. 


N 


3. Require the user to prove his or her identity for each service invoked. Also 
require that servers prove their identity to clients. 


In asmall, closed environment in which all systems are owned and operated by 
a single organization, the first or perhaps the second strategy may suffice.° But in a 
more open environment in which network connections to other machines are 
supported, the third approach is needed to protect user information and resources 
housed at the server. Kerberos supports this third approach. Kerberos assumes a 
distributed client/server architecture and employs one or more Kerberos servers to 
provide an authentication service. 

The first published report on Kerberos [STEI88] listed the following 
requirements. 


e Secure: A network eavesdropper should not be able to obtain the necessary 
information to impersonate a user. More generally, Kerberos should be strong 
enough that a potential opponent does not find it to be the weak link. 


e Reliable: For all services that rely on Kerberos for access control, lack of 
availability of the Kerberos service means lack of availability of the supported 
services. Hence, Kerberos should be highly reliable and should employ a 
distributed server architecture with one system able to back up another. 


e Transparent: Ideally, the user should not be aware that authentication is taking 
place beyond the requirement to enter a password. 


e Scalable: The system should be capable of supporting large numbers of clients 
and servers. This suggests a modular, distributed architecture. 


To support these requirements, the overall scheme of Kerberos is that of a 
trusted third-party authentication service that uses a protocol based on that pro- 
posed by Needham and Schroeder [NEED78], which was discussed in Section 15.2. 


°However, even a closed environment faces the threat of attack by a disgruntled employee. 
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It is trusted in the sense that clients and servers trust Kerberos to mediate their 
mutual authentication. Assuming the Kerberos protocol is well designed, then the 
authentication service is secure if the Kerberos server itself is secure.’ 


Kerberos Version 4 


Version 4 of Kerberos makes use of DES, in a rather elaborate protocol, to pro- 
vide the authentication service. Viewing the protocol as a whole, it is difficult to 
see the need for the many elements contained therein. Therefore, we adopt a strat- 
egy used by Bill Bryant of Project Athena [BRYA88] and build up to the full 
protocol by looking first at several hypothetical dialogues. Each successive dia- 
logue adds additional complexity to counter security vulnerabilities revealed in 
the preceding dialogue. 
After examining the protocol, we look at some other aspects of version 4. 


A SIMPLE AUTHENTICATION DIALOGUE In an unprotected network environment, 
any client can apply to any server for service. The obvious security risk is that of 
impersonation. An opponent can pretend to be another client and obtain 
unauthorized privileges on server machines. To counter this threat, servers must be 
able to confirm the identities of clients who request service. Each server can be 
required to undertake this task for each client/server interaction, but in an open 
environment, this places a substantial burden on each server. 

An alternative is to use an authentication server (AS) that knows the pass- 
words of all users and stores these in a centralized database. In addition, the AS 
shares a unique secret key with each server. These keys have been distributed 
physically or in some other secure manner. Consider the following hypothetical 


dialogue: 
(1) CAS: ID¢||Pc||IDy 
(2) ASC: Ticket 
(3) CV:  ID¢|| Ticket 
Ticket = E(K,, [IDc|| ADc||IDy]) 
where 
C  =client 
AS = authentication server 
V = server 
IDc = identifier of user on C 


7Remember that the security of the Kerberos server should not automatically be assumed but must be 
guarded carefully (e.g., in a locked room). It is well to remember the fate of the Greek Kerberos, whom 
Hercules was ordered by Eurystheus to capture as his Twelfth Labor: “Hercules found the great dog on its 
chain and seized it by the throat. At once the three heads tried to attack, and Kerberos lashed about with his 
powerful tail. Hercules hung on grimly, and Kerberos relaxed into unconsciousness. Eurystheus may have 
been surprised to see Hercules alive—when he saw the three slavering heads and the huge dog they 
belonged to he was frightened out of his wits, and leapt back into the safety of his great bronze jar.” From 
The Hamlyn Concise Dictionary of Greek and Roman Mythology, by Michael Stapleton, Hamlyn, 1982. 
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IDy = identifier of V 

Pc = password of user on C 

ADc = network address of C 

K, = secret encryption key shared by AS and V 


In this scenario, the user logs on to a workstation and requests access to server V. 
The client module C in the user’s workstation requests the user’s password and 
then sends a message to the AS that includes the user’s ID, the server’s ID, and the 
user’s password. The AS checks its database to see if the user has supplied the 
proper password for this user ID and whether this user is permitted access to 
server V. If both tests are passed, the AS accepts the user as authentic and must 
now convince the server that this user is authentic. To do so, the AS creates a ticket 
that contains the user’s ID and network address and the server’s ID. This ticket is 
encrypted using the secret key shared by the AS and this server. This ticket is then 
sent back to C. Because the ticket is encrypted, it cannot be altered by C or by an 
opponent. 

With this ticket, C can now apply to V for service. C sends a message to V con- 
taining C’s ID and the ticket. V decrypts the ticket and verifies that the user ID in 
the ticket is the same as the unencrypted user ID in the message. If these two match, 
the server considers the user authenticated and grants the requested service. 

Each of the ingredients of message (3) is significant. The ticket is encrypted to 
prevent alteration or forgery. The server’s ID (JDy) is included in the ticket so that 
the server can verify that it has decrypted the ticket properly. /D¢ is included in the 
ticket to indicate that this ticket has been issued on behalf of C. Finally, AD¢ serves 
to counter the following threat. An opponent could capture the ticket transmitted in 
message (2), then use the name /D¢ and transmit a message of form (3) from 
another workstation. The server would receive a valid ticket that matches the user 
ID and grant access to the user on that other workstation. To prevent this attack, the 
AS includes in the ticket the network address from which the original request came. 
Now the ticket is valid only if it is transmitted from the same workstation that ini- 
tially requested the ticket. 


A More SECURE AUTHENTICATION DIALOGUE Although the foregoing scenario 
solves some of the problems of authentication in an open network environment, 
problems remain. Two in particular stand out. First, we would like to minimize the 
number of times that a user has to enter a password. Suppose each ticket can be 
used only once. If user C logs on to a workstation in the morning and wishes to 
check his or her mail at a mail server, C must supply a password to get a ticket for 
the mail server. If C wishes to check the mail several times during the day, each 
attempt requires reentering the password. We can improve matters by saying that 
tickets are reusable. For a single logon session, the workstation can store the mail 
server ticket after it is received and use it on behalf of the user for multiple accesses 
to the mail server. 

However, under this scheme, it remains the case that a user would need a new 
ticket for every different service. If a user wished to access a print server, a mail 
server, a file server, and so on, the first instance of each access would require a new 
ticket and hence require the user to enter the password. 


456 CHAPTER 15 / USER AUTHENTICATION 


The second problem is that the earlier scenario involved a plaintext transmis- 
sion of the password [message (1)]. An eavesdropper could capture the password 
and use any service accessible to the victim. 

To solve these additional problems, we introduce a scheme for avoiding plain- 
text passwords and a new server, known as the ticket-granting server (TGS). The 
new (but still hypothetical) scenario is as follows. 


Once per user logon session: 
() CAS: — ID¢||ID igs 
(2) AS>C: — E(K,, Tickets) 
Once per type of service: 
(3) C>TGS: ID¢||[Dy|| Tickets, 
(4) TGS—C: Ticket, 
Once per service session: 


(5) COV: = Dell Ticket, 


Ticketygs = E(Kgs, [ID ¢|| AD cll Digs | TS; | Lifetime,}) 
Ticket, = E(K,, UDc|| AD¢||ID,|| TS>]|| Lifetimes) 


The new service, TGS, issues tickets to users who have been authenticated to 
AS. Thus, the user first requests a ticket-granting ticket (Ticket,,,) from the AS. The 
client module in the user workstation saves this ticket. Each time the user requires 
access to a new service, the client applies to the TGS, using the ticket to authenticate 
itself. The TGS then grants a ticket for the particular service. The client saves each 
service-granting ticket and uses it to authenticate its user to a server each time a 
particular service is requested. Let us look at the details of this scheme: 


1. The client requests a ticket-granting ticket on behalf of the user by sending its 
user’s ID to the AS, together with the TGS ID, indicating a request to use the 
TGS service. 


. The AS responds with a ticket that is encrypted with a key that is derived from 
the user’s password (K,), which is already stored at the AS. When this response 
arrives at the client, the client prompts the user for his or her password, gener- 
ates the key, and attempts to decrypt the incoming message. If the correct pass- 
word is supplied, the ticket is successfully recovered. 


nN 


Because only the correct user should know the password, only the correct user 
can recover the ticket. Thus, we have used the password to obtain credentials from 
Kerberos without having to transmit the password in plaintext. The ticket itself 
consists of the ID and network address of the user, and the ID of the TGS. This cor- 
responds to the first scenario. The idea is that the client can use this ticket to request 
multiple service-granting tickets. So the ticket-granting ticket is to be reusable. 
However, we do not wish an opponent to be able to capture the ticket and use it. 
Consider the following scenario: An opponent captures the login ticket and waits 
until the user has logged off his or her workstation. Then the opponent either gains 
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access to that workstation or configures his workstation with the same network 
address as that of the victim. The opponent would be able to reuse the ticket to 
spoof the TGS. To counter this, the ticket includes a timestamp, indicating the date 
and time at which the ticket was issued, and a lifetime, indicating the length of time 
for which the ticket is valid (e.g., eight hours). Thus, the client now has a reusable 
ticket and need not bother the user for a password for each new service request. 
Finally, note that the ticket-granting ticket is encrypted with a secret key known 
only to the AS and the TGS. This prevents alteration of the ticket. The ticket is reen- 
crypted with a key based on the user’s password. This assures that the ticket can be 
recovered only by the correct user, providing the authentication. 

Now that the client has a ticket-granting ticket, access to any server can be 
obtained with steps 3 and 4. 


3. The client requests a service-granting ticket on behalf of the user. For this pur- 
pose, the client transmits a message to the TGS containing the user’s ID, the 
ID of the desired service, and the ticket-granting ticket. 


4. The TGS decrypts the incoming ticket using a key shared only by the AS and 
the TGS (K,,,) and verifies the success of the decryption by the presence of its 
ID. It checks to make sure that the lifetime has not expired. Then it compares 
the user ID and network address with the incoming information to authenti- 
cate the user. If the user is permitted access to the server V, the TGS issues a 
ticket to grant access to the requested service. 


The service-granting ticket has the same structure as the ticket-granting ticket. 
Indeed, because the TGS is a server, we would expect that the same elements are 
needed to authenticate a client to the TGS and to authenticate a client to an appli- 
cation server. Again, the ticket contains a timestamp and lifetime. If the user wants 
access to the same service at a later time, the client can simply use the previously 
acquired service-granting ticket and need not bother the user for a password. Note 
that the ticket is encrypted with a secret key (K,) known only to the TGS and the 
server, preventing alteration. 

Finally, with a particular service-granting ticket, the client can gain access to 
the corresponding service with step 5. 


5. The client requests access to a service on behalf of the user. For this purpose, 
the client transmits a message to the server containing the user’s ID and the 
service-granting ticket. The server authenticates by using the contents of the 
ticket. 


This new scenario satisfies the two requirements of only one password query 
per user session and protection of the user password. 


THE VERSION 4 AUTHENTICATION DiALoGueE Although the foregoing scenario 
enhances security compared to the first attempt, two additional problems remain. 
The heart of the first problem is the lifetime associated with the ticket-granting 
ticket. If this lifetime is very short (e.g., minutes), then the user will be repeatedly 
asked for a password. If the lifetime is long (e.g., hours), then an opponent has a 
greater opportunity for replay. An opponent could eavesdrop on the network and 
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capture a copy of the ticket-granting ticket and then wait for the legitimate user to 
log out. Then the opponent could forge the legitimate user’s network address and 
send the message of step (3) to the TGS. This would give the opponent unlimited 
access to the resources and files available to the legitimate user. 

Similarly, if an opponent captures a service-granting ticket and uses it before it 
expires, the opponent has access to the corresponding service. 

Thus, we arrive at an additional requirement. A network service (the TGS or 
an application service) must be able to prove that the person using a ticket is the 
same person to whom that ticket was issued. 

The second problem is that there may be a requirement for servers to authen- 
ticate themselves to users. Without such authentication, an opponent could sabotage 
the configuration so that messages to a server were directed to another location. The 
false server would then be in a position to act as a real server and capture any infor- 
mation from the user and deny the true service to the user. 

We examine these problems in turn and refer to Table 15.1, which shows the 
actual Kerberos protocol. 

First, consider the problem of captured ticket-granting tickets and the need to 
determine that the ticket presenter is the same as the client for whom the ticket was 
issued. The threat is that an opponent will steal the ticket and use it before it expires. 
To get around this problem, let us have the AS provide both the client and the TGS 
with a secret piece of information in a secure manner. Then the client can prove its 
identity to the TGS by revealing the secret information—again in a secure manner. 
An efficient way of accomplishing this is to use an encryption key as the secure 
information; this is referred to as a session key in Kerberos. 


Table 15.1 Summary of Kerberos Version 4 Message Exchanges 
CAS ID, ll Digs 
ASC E(Ke [Kes 

Ticketigs = E(Kigs, [Ke, tgs | IDcll ADcll Digs ll TS ll Lifetime]) 


ll TS; 
Il LDigs ll TS \l Lifetimes || Ticket,.s]) 


(a) Authentication Service Exchange to obtain ticket-granting ticket 


C—TGS ID, \\ Ticket,g; || Authenticator, 
TGS > C E(Kz tgs, [Ke, y || [Dy ll TS4 || Ticket,]) 
Ticket, = E(Kygs [Ke, 195 || IDcll ADcl IDjgs ll TS2 || Lifetime ]) 
Ticket, = E(K,, [K. , ll IDc!l ADcll ID, |! TS4 ll Lifetime,]) 
Authenticator, = E(Ke igs, [ID !l AD¢ |! TS3]) 


(b) Ticket-Granting Service Exchange to obtain service-granting ticket 
CV _ Ticket, || Authenticator, 


V-C E(K,,,[TS; + 1]) (for mutual authentication) 


Ticket, = E(K,, [K,. , || Dell AD¢ll ID, II TS, |! Lifetime,]) 


Authenticator, = E (K,.,, [Dc || ADc Il TSs]) 


(c) Client/Server Authentication Exchange to obtain service 
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Table 15.1a shows the technique for distributing the session key. As before, 
the client sends a message to the AS requesting access to the TGS. The AS responds 
with a message, encrypted with a key derived from the user’s password (K,), that 
contains the ticket. The encrypted message also contains a copy of the session key, 
K.4gs, Where the subscripts indicate that this is a session key for C and TGS. 
Because this session key is inside the message encrypted with K,, only the user’s 
client can read it. The same session key is included in the ticket, which can be read 
only by the TGS. Thus, the session key has been securely delivered to both C and 
the TGS. 

Note that several additional pieces of information have been added to this 
first phase of the dialogue. Message (1) includes a timestamp, so that the AS knows 
that the message is timely. Message (2) includes several elements of the ticket in a 
form accessible to C. This enables C to confirm that this ticket is for the TGS and to 
learn its expiration time. 

Armed with the ticket and the session key, C is ready to approach the TGS. As 
before, C sends the TGS a message that includes the ticket plus the ID of the 
requested service (message (3) in Table 15.1b). In addition, C transmits an authenti- 
cator, which includes the ID and address of C’s user and a timestamp. Unlike the 
ticket, which is reusable, the authenticator is intended for use only once and has a 
very short lifetime. The TGS can decrypt the ticket with the key that it shares 
with the AS. This ticket indicates that user C has been provided with the session key 
K. gs" In effect, the ticket says, “Anyone who uses K,.,,, must be C.” The TGS uses the 
session key to decrypt the authenticator. The TGS can then check the name and 
address from the authenticator with that of the ticket and with the network address 
of the incoming message. If all match, then the TGS is assured that the sender of the 
ticket is indeed the ticket’s real owner. In effect, the authenticator says, “At time 
TS3, Il hereby use K,.;;.” Note that the ticket does not prove anyone’s identity but is 
a way to distribute keys securely. It is the authenticator that proves the client’s iden- 
tity. Because the authenticator can be used only once and has a short lifetime, the 
threat of an opponent stealing both the ticket and the authenticator for presentation 
later is countered. 

The reply from the TGS in message (4) follows the form of message (2). The 
message is encrypted with the session key shared by the TGS and C and includes a 
session key to be shared between C and the server V, the ID of V, and the timestamp 
of the ticket. The ticket itself includes the same session key. 

C now has a reusable service-granting ticket for V. When C presents this ticket, 
as shown in message (5), it also sends an authenticator. The server can decrypt the 
ticket, recover the session key, and decrypt the authenticator. 

If mutual authentication is required, the server can reply as shown in message (6) 
of Table 15.1. The server returns the value of the timestamp from the authenticator, 
incremented by 1, and encrypted in the session key. C can decrypt this message to 
recover the incremented timestamp. Because the message was encrypted by the session 
key, Cis assured that it could have been created only by V. The contents of the message 
assure C that this is not a replay of an old reply. 

Finally, at the conclusion of this process, the client and server share a secret 
key. This key can be used to encrypt future messages between the two or to 
exchange a new random session key for that purpose. 
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Table 15.2 summarizes the justification for each of the elements in the 
Kerberos protocol, and Figure 15.1 provides a simplified overview of the action. 


Table 15.2 Rationale for the Elements of the Kerberos Version 4 Protocol 


Message (1) 
IDc 
TD igs 
TS, 
Message (2) 


TD gs 

TS 
Lifetime 
Ticketgs 


Client requests ticket-granting ticket. 

Tells AS identity of user from this client. 

Tells AS that user requests access to TGS. 

Allows AS to verify that client’s clock is synchronized with that of AS. 


AS returns ticket-granting ticket. 


Encryption is based on user’s password, enabling AS and client to verify 
password, and protecting contents of message (2). 


Copy of session key accessible to client created by AS to permit secure 
exchange between client and TGS without requiring them to share a 
permanent key. 


Confirms that this ticket is for the TGS. 
Informs client of time this ticket was issued. 
Informs client of the lifetime of this ticket. 


Ticket to be used by client to access TGS. 


(a) Authentication Service Exchange 


Message (3) 
IDy 
Ticketyg, 
Authenticator,. 
Message (4) 
Ie tgs 


Ue ¥ 


IDy 
TS4 
Tickety 
Ticketygs 


tgs 


Lifetime 


Authenticator,. 


Client requests service-granting ticket. 


Tells TGS that user requests access to server V. 

Assures TGS that this user has been authenticated by AS. 
Generated by client to validate ticket. 

TGS returns service-granting ticket. 

Key shared only by C and TGS protects contents of message (4). 


Copy of session key accessible to client created by TGS to permit secure 
exchange between client and server without requiring them to share 
a permanent key. 


Confirms that this ticket is for server V. 

Informs client of time this ticket was issued. 

Ticket to be used by client to access server V. 

Reusable so that user does not have to reenter password. 


Ticket is encrypted with key known only to AS and TGS, to prevent 
tampering. 


Copy of session key accessible to TGS used to decrypt authenticator, 
thereby authenticating ticket. 


Indicates the rightful owner of this ticket. 


Prevents use of ticket from workstation other than one that initially 
requested the ticket. 


Assures server that it has decrypted ticket properly. 
Informs TGS of time this ticket was issued. 
Prevents replay after ticket has expired. 


Assures TGS that the ticket presenter is the same as the client for whom 
the ticket was issued has very short lifetime to prevent replay. 


DS oe Authenticator is encrypted with key known only to client and TGS, to pre- 
vent tampering. 

IDe Must match ID in ticket to authenticate ticket. 

ADc Must match address in ticket to authenticate ticket. 

TS3 Informs TGS of time this authenticator was generated. 


(b) Ticket-Granting Service Exchange 


Message (5) Client requests service. 
Tickety Assures server that this user has been authenticated by AS. 
Authenticator, Generated by client to validate ticket. 
Message (6) Optional authentication of server to client. 
KG Assures C that this message is from V. 
Sg oP il Assures C that this is not a replay of an old reply. 


Ticket, Reusable so that client does not need to request a new ticket from TGS 
for each access to the same server. 


Ticket is encrypted with key known only to TGS and server, to prevent 
tampering. 


Copy of session key accessible to client; used to decrypt authenticator, 
thereby authenticating ticket. 


Indicates the rightful owner of this ticket. 


Prevents use of ticket from workstation other than one that initially 
requested the ticket. 


Assures server that it has decrypted ticket properly. 
Informs server of time this ticket was issued. 
Lifetime, Prevents replay after ticket has expired. 


Authenticator, Assures server that the ticket presenter is the same as the client for whom 
the ticket was issued; has very short lifetime to prevent replay. 


Tos Authenticator is encrypted with key known only to client and server, to 
prevent tampering. 


Must match ID in ticket to authenticate ticket. 
Must match address in ticket to authenticate ticket. 


Informs server of time this authenticator was generated. 


(c) Client/Server Authentication Exchange 


KERBEROS REALMS AND MULTIPLE KERBERI A full-service Kerberos environment 
consisting of a Kerberos server, a number of clients, and a number of application 
servers requires the following: 


1. The Kerberos server must have the user ID and hashed passwords of all partic- 
ipating users in its database. All users are registered with the Kerberos server. 


2. The Kerberos server must share a secret key with each server. All servers are 
registered with the Kerberos server. 
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1. User logs on to 
workstation and 
requests service on host. 


3. Workstation prompts 
user for password and 
uses password to decrypt 
incoming message, then 
sends ticket and 
authenticator that 
contains user's name, 
network address, and 
time to TGS. Once per 


5. Workstation sends Service session 
ticket and authenticator 


to server. 


2. AS verifies user's access right in 
database, creates ticket-granting ticket 
and session key. Results are encrypted 
using key derived from user's password. 


Once per 
user logon Kerberos 
session 


Authentication 
server (AS) 


Ticket- 
granting 
server (TGS) 


4. TGS decrypts ticket and 
authenticator, verifies request, 
then creates ticket for requested 


server. 


6. Server verifies that 
ticket and authenticator 
match, then grants access 
to service. If mutual 
authentication is 
required, server returns 
an authenticator. 


Figure 15.1 Overview of Kerberos 


Such an environment is referred to as a Kerberos realm. The concept of 
realm can be explained as follows. A Kerberos realm is a set of managed nodes 
that share the same Kerberos database. The Kerberos database resides on the 
Kerberos master computer system, which should be kept in a physically secure 
room. A read-only copy of the Kerberos database might also reside on other 
Kerberos computer systems. However, all changes to the database must be made 
on the master computer system. Changing or accessing the contents of a 
Kerberos database requires the Kerberos master password. A related concept is 
that of a Kerberos principal, which is a service or user that is known to the 
Kerberos system. Each Kerberos principal is identified by its principal name. 
Principal names consist of three parts: a service or user name, an instance name, 
and a realm name 

Networks of clients and servers under different administrative organiza- 
tions typically constitute different realms. That is, it generally is not practical or 
does not conform to administrative policy to have users and servers in one 
administrative domain registered with a Kerberos server elsewhere. However, 
users in one realm may need access to servers in other realms, and some servers 
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may be willing to provide service to users from other realms, provided that those 
users are authenticated. 

Kerberos provides a mechanism for supporting such interrealm authentication. 
For two realms to support interrealm authentication, a third requirement is added: 


3. The Kerberos server in each interoperating realm shares a secret key with the 
server in the other realm. The two Kerberos servers are registered with each other. 


The scheme requires that the Kerberos server in one realm trust the Kerberos 
server in the other realm to authenticate its users. Furthermore, the participating 
servers in the second realm must also be willing to trust the Kerberos server in the 
first realm. 

With these ground rules in place, we can describe the mechanism as follows 
(Figure 15.2): A user wishing service on a server in another realm needs a ticket for 
that server. The user’s client follows the usual procedures to gain access to the local 
TGS and then requests a ticket-granting ticket for a remote TGS (TGS in another 
realm). The client can then apply to the remote TGS for a service-granting ticket for 
the desired server in the realm of the remote TGS. 

The details of the exchanges illustrated in Figure 15.2 are as follows (compare 
Table 15.1). 


() CAS: ID, Ml IDygs ll TS, 

(2) ASC: E(K¢, [Ke, tgs || [Digs ll TS ll Lifetime, |l Ticket,gs}) 
(3) C-—TGS: TD gsrem || Ticket;gs || Authenticator, 

(4) TGS >C: E(Ke tgs, [Ke, tgsrem I TD gsrem I TS, I Ticketyesrem|) 
(5) C>TGS em: LD rem || Ticketygsrem |l Authenticator, 

(6) TGS em —C: UK rosreiie [Ke, vrem I LD yrem I TS¢ I Ticket, ren)) 
(7) C= Viem! Ticket,,em || Authenticator, 

The ticket presented to the remote server (V,,,,,) indicates the realm in which 
the user was originally authenticated. The server chooses whether to honor the 
remote request. 

One problem presented by the foregoing approach is that it does not scale well to 


many realms. If there are N realms, then there must be M(N — 1)/2 secure key 
exchanges so that each Kerberos realm can interoperate with all other Kerberos realms. 


Kerberos Version 5 


Kerberos version 5 is specified in RFC 4120 and provides a number of improve- 
ments over version 4 [KOHL94]. To begin, we provide an overview of the changes 
from version 4 to version 5 and then look at the version 5 protocol. 


DIFFERENCES BETWEEN VERSIONS 4 AND 5 Version 5 is intended to address the 


limitations of version 4 in two areas: environmental shortcomings and technical 
deficiencies. Let us briefly summarize the improvements in each area.® 


8The following discussion follows the presentation in [KOHL94]. 
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Realm A 
are Kerberos 


4. Ticket for remote TGS 


J Noular sonbay */ 


Kerberos 


Server 


Realm B 


Figure 15.2 Request for Service in Another Realm 


Kerberos version 4 was developed for use within the Project Athena environ- 
ment and, accordingly, did not fully address the need to be of general purpose. This 
led to the following environmental shortcomings. 


1. Encryption system dependence: Version 4 requires the use of DES. Export 
restriction on DES as well as doubts about the strength of DES were thus of 
concern. In version 5, ciphertext is tagged with an encryption-type identifier 
so that any encryption technique may be used. Encryption keys are tagged 
with a type and a length, allowing the same key to be used in different 


WN 


mn 
. 
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algorithms and allowing the specification of different variations on a given 
algorithm. 


. Internet protocol dependence: Version 4 requires the use of Internet Protocol 


(IP) addresses. Other address types, such as the ISO network address, are not 
accommodated. Version 5 network addresses are tagged with type and length, 
allowing any network address type to be used. 


Message byte ordering: In version 4, the sender of a message employs a byte 
ordering of its own choosing and tags the message to indicate least significant 
byte in lowest address or most significant byte in lowest address. This tech- 
niques works but does not follow established conventions. In version 5, all mes- 
sage structures are defined using Abstract Syntax Notation One (ASN.1) and 
Basic Encoding Rules (BER), which provide an unambiguous byte ordering. 


Ticket lifetime: Lifetime values in version 4 are encoded in an 8-bit quantity in 
units of five minutes. Thus, the maximum lifetime that can be expressed is 
2° x 5 = 1280 minutes (a little over 21 hours). This may be inadequate for some 
applications (e.g., a long-running simulation that requires valid Kerberos creden- 
tials throughout execution). In version 5, tickets include an explicit start time and 
end time, allowing tickets with arbitrary lifetimes. 


Authentication forwarding: Version 4 does not allow credentials issued to one 
client to be forwarded to some other host and used by some other client. This 
capability would enable a client to access a server and have that server access 
another server on behalf of the client. For example, a client issues a request to a 
print server that then accesses the client’s file from a file server, using the client’s 
credentials for access. Version 5 provides this capability. 


Interrealm authentication: In version 4, interoperability among N realms 
requires on the order of N? Kerberos-to-Kerberos relationships, as described 
earlier. Version 5 supports a method that requires fewer relationships, as 
described shortly. 


Apart from these environmental limitations, there are technical deficiencies in 


the version 4 protocol itself. Most of these deficiencies were documented in [BELL90], 
and version 5 attempts to address these. The deficiencies are the following. 


1. 


nN 
° 


Double encryption: Note in Table 15.1 [messages (2) and (4)] that tickets pro- 
vided to clients are encrypted twice—once with the secret key of the target 
server and then again with a secret key known to the client. The second 
encryption is not necessary and is computationally wasteful. 


PCBC encryption: Encryption in version 4 makes use of a nonstandard mode of 
DES known as propagating cipher block chaining (PCBC).”’ It has been demon- 
strated that this mode is vulnerable to an attack involving the interchange of 
ciphertext blocks [KOHL89]. PCBC was intended to provide an integrity check as 
part of the encryption operation. Version 5 provides explicit integrity mechanisms, 
allowing the standard CBC mode to be used for encryption. In particular, a check- 
sum or hash code is attached to the message prior to encryption using CBC. 


°This is described in Appendix 15A. 
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3. Session keys: Each ticket includes a session key that is used by the client to 
encrypt the authenticator sent to the service associated with that ticket. In addi- 
tion, the session key may subsequently be used by the client and the server to 
protect messages passed during that session. However, because the same ticket 
may be used repeatedly to gain service from a particular server, there is the risk 
that an opponent will replay messages from an old session to the client or the 
server. In version 5, it is possible for a client and server to negotiate a subsession 
key, which is to be used only for that one connection. A new access by the client 
would result in the use of a new subsession key. 


4. Password attacks: Both versions are vulnerable to a password attack. The mes- 
sage from the AS to the client includes material encrypted with a key based on 
the client’s password.!° An opponent can capture this message and attempt to 
decrypt it by trying various passwords. If the result of a test decryption is of the 
proper form, then the opponent has discovered the client’s password and may 
subsequently use it to gain authentication credentials from Kerberos. This is 
the same type of password attack described in Chapter 20, with the same kinds 
of countermeasures being applicable. Version 5 does provide a mechanism 
known as preauthentication, which should make password attacks more diffi- 
cult, but it does not prevent them. 


THE VERSION 5 AUTHENTICATION DiALOGuE Table 15.3 summarizes the basic 
version 5 dialogue. This is best explained by comparison with version 4 (Table 15.1). 


Table 15.3 Summary of Kerberos Version 5 Message Exchanges 


C—AS Options || [D.|| Realm, \| [Digs || Times || Nonce, 
AS—>C Realme \ ID cll Ticketigs | E(K¢, [Kegs !! Times || Nonce; \| Realimygs || ID 95]) 


Ticketig, = E(Kygs, [Flags || Kegs || Realm, || [Dc || ADc|l Times]) 


(a) Authentication Service Exchange to obtain ticket-granting ticket 
C—TGS Options II ZD,, || Times || Noncey || Ticket,.. || Authenticator, 
TGS—C Realm, \| ID cll Ticket, || E(K eyes, [Ke || Times || Nonce, || Realm, || 1D,]) 
Ticket, = E( Kgs, [Flags || Kegs || Realm, || ID¢ || ADc|l Times]) 
Ticket, = E(K,, [Flags || K,,, |] Realm, || ID¢ || ADc¢|l Times]) 
Authenticator, = E(K e495, [ID || Realm, |l TS;]) 


(b) Ticket-Granting Service Exchange to obtain service-granting ticket 
CV Options || Ticket, || Authenticator, 
V>C_ Ex., [TS2 || Subkey || Seq¥] 


Ticket, = E(K,, [Flag || K,., |] Realm, || ID¢ || ADcll Times]) 
Authenticator, = E(K,,, [ID¢ || Relam, || TS, || Subkey || Seq#]) 


(c) Client/Server Authentication Exchange to obtain service 


104 ppendix 15A describes the mapping of passwords to encryption keys. 
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First, consider the authentication service exchange. Message (1) is a client 
request for a ticket-granting ticket. As before, it includes the ID of the user and the 
TGS. The following new elements are added: 


e Realm: Indicates realm of user 
¢ Options: Used to request that certain flags be set in the returned ticket 
e Times: Used by the client to request the following time settings in the ticket: 


—from: the desired start time for the requested ticket 
—till: the requested expiration time for the requested ticket 
—rtime: requested renew-till time 


e Nonce: A random value to be repeated in message (2) to assure that the 
response is fresh and has not been replayed by an opponent 


Message (2) returns a ticket-granting ticket, identifying information for the 
client, and a block encrypted using the encryption key based on the user’s password. 
This block includes the session key to be used between the client and the TGS, times 
specified in message (1), the nonce from message (1), and TGS identifying informa- 
tion. The ticket itself includes the session key, identifying information for the client, 
the requested time values, and flags that reflect the status of this ticket and the 
requested options. These flags introduce significant new functionality to version 5. 
For now, we defer a discussion of these flags and concentrate on the overall struc- 
ture of the version 5 protocol. 

Let us now compare the ticket-granting service exchange for versions 4 and 
5. We see that message (3) for both versions includes an authenticator, a ticket, 
and the name of the requested service. In addition, version 5 includes requested 
times and options for the ticket and a nonce—all with functions similar to those of 
message (1). The authenticator itself is essentially the same as the one used in 
version 4. 

Message (4) has the same structure as message (2). It returns a ticket plus 
information needed by the client, with the information encrypted using the session 
key now shared by the client and the TGS. 

Finally, for the client/server authentication exchange, several new features 
appear in version 5. In message (5), the client may request as an option that mutual 
authentication is required. The authenticator includes several new fields: 


e Subkey: The client’s choice for an encryption key to be used to protect this 
specific application session. If this field is omitted, the session key from the 
ticket (K,,) is used. 


e Sequence number: An optional field that specifies the starting sequence num- 
ber to be used by the server for messages sent to the client during this session. 
Messages may be sequence numbered to detect replays. 


If mutual authentication is required, the server responds with message (6). 
This message includes the timestamp from the authenticator. Note that in version 4, 
the timestamp was incremented by one. This is not necessary in version 5, because 
the nature of the format of messages is such that it is not possible for an opponent 
to create message (6) without knowledge of the appropriate encryption keys. 
The subkey field, if present, overrides the subkey field, if present, in message (5). 
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The optional sequence number field specifies the starting sequence number to be 
used by the client. 


Ticket Fiacs The flags field included in tickets in version 5 supports expanded 
functionality compared to that available in version 4. Table 15.4 summarizes the 
flags that may be included in a ticket. 

The INITIAL flag indicates that this ticket was issued by the AS, not by the 
TGS. When a client requests a service-granting ticket from the TGS, it presents a 
ticket-granting ticket obtained from the AS. In version 4, this was the only way to 
obtain a service-granting ticket. Version 5 provides the additional capability that the 
client can get a service-granting ticket directly from the AS. The utility of this is as 
follows: A server, such as a password-changing server, may wish to know that the 
client’s password was recently tested. 

The PRE-AUTHENT flag, if set, indicates that when the AS received the ini- 
tial request [message (1)], it authenticated the client before issuing a ticket. The 
exact form of this preauthentication is left unspecified. As an example, the MIT 
implementation of version 5 has encrypted timestamp preauthentication, enabled 
by default. When a user wants to get a ticket, it has to send to the AS a preauthenti- 
cation block containing a random confounder, a version number, and a timestamp 
all encrypted in the client’s password-based key. The AS decrypts the block and will 
not send a ticket-granting ticket back unless the timestamp in the preauthentication 
block is within the allowable time skew (time interval to account for clock drift and 
network delays). Another possibility is the use of a smart card that generates 


Table 15.4 Kerberos Version 5 Flags 


INITIAL This ticket was issued using the AS protocol and not issued based on a ticket- 


granting ticket. 


PRE-AUTHENT During initial authentication, the client was authenticated by the KDC before 


a ticket was issued. 


HW-AUTHENT The protocol employed for initial authentication required the use of hard- 


ware expected to be possessed solely by the named client. 


RENEWABLE Tells TGS that this ticket can be used to obtain a replacement ticket that 


expires at a later date. 


MAY-POSTDATE 


POSTDATED 


INVALID 
PROXIABLE 


PROXY 
FORWARDABLE 


FORWARDED 


Tells TGS that a postdated ticket may be issued based on this ticket-granting 
ticket. 


Indicates that this ticket has been postdated; the end server can check the 
authtime field to see when the original authentication occurred. 


This ticket is invalid and must be validated by the KDC before use. 


Tells TGS that a new service-granting ticket with a different network address 
may be issued based on the presented ticket. 


Indicates that this ticket is a proxy. 


Tells TGS that a new ticket-granting ticket with a different network address 
may be issued based on this ticket-granting ticket. 


Indicates that this ticket has either been forwarded or was issued based on 
authentication involving a forwarded ticket-granting ticket. 
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continually changing passwords that are included in the preauthenticated messages. 
The passwords generated by the card can be based on a user’s password but be 
transformed by the card so that, in effect, arbitrary passwords are used. This pre- 
vents an attack based on easily guessed passwords. If a smart card or similar device 
was used, this is indicated by the HW-AUTHENT flag. 

When a ticket has a long lifetime, there is the potential for it to be stolen and 
used by an opponent for a considerable period. If a short lifetime is used to lessen 
the threat, then overhead is involved in acquiring new tickets. In the case of a ticket- 
granting ticket, the client would either have to store the user’s secret key, which is 
clearly risky, or repeatedly ask the user for a password. A compromise scheme is the 
use of renewable tickets. A ticket with the RENEWABLE flag set includes two 
expiration times: one for this specific ticket and one that is the latest permissible 
value for an expiration time. A client can have the ticket renewed by presenting it to 
the TGS with a requested new expiration time. If the new time is within the limit of 
the latest permissible value, the TGS can issue a new ticket with a new session time 
and a later specific expiration time. The advantage of this mechanism is that the 
TGS may refuse to renew a ticket reported as stolen. 

A client may request that the AS provide a ticket-granting ticket with the 
MAY-POSTDATE flag set. The client can then use this ticket to request a ticket that 
is flagged as POSTDATED and INVALID from the TGS. Subsequently, the client 
may submit the postdated ticket for validation. This scheme can be useful for run- 
ning a long batch job on a server that requires a ticket periodically. The client can 
obtain a number of tickets for this session at once, with spread out time values. All 
but the first ticket are initially invalid. When the execution reaches a point in time 
when a new ticket is required, the client can get the appropriate ticket validated. 
With this approach, the client does not have to repeatedly use its ticket-granting 
ticket to obtain a service-granting ticket. 

In version 5, it is possible for a server to act as a proxy on behalf of a client, in 
effect adopting the credentials and privileges of the client to request a service from 
another server. If a client wishes to use this mechanism, it requests a ticket-granting 
ticket with the PROXIABLE flag set. When this ticket is presented to the TGS, the 
TGS is permitted to issue a service-granting ticket with a different network address; 
this latter ticket will have its PROXY flag set. An application receiving such a ticket 
may accept it or require additional authentication to provide an audit trail.!! 

The proxy concept is a limited case of the more powerful forwarding proce- 
dure. If a ticket is set with the FORWARDABLE flag, a TGS can issue to the 
requestor a ticket-granting ticket with a different network address and the FOR- 
WARDED flag set. This ticket then can be presented to a remote TGS. This capa- 
bility allows a client to gain access to a server on another realm without requiring 
that each Kerberos maintain a secret key with Kerberos servers in every other 
realm. For example, realms could be structured hierarchically. Then a client could 
walk up the tree to a common node and then back down to reach a target realm. 
Each step of the walk would involve forwarding a ticket-granting ticket to the next 
TGS in the path. 


‘lor a discussion of some of the possible uses of the proxy capability, see [NEUM93b]. 
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15.4 REMOTE USER AUTHENTICATION USING 


ASYMMETRIC ENCRYPTION 


Mutual Authentication 


In Chapter 14, we presented one approach to the use of public-key encryption for 
the purpose of session-key distribution (Figure 14.8). This protocol assumes that 
each of the two parties is in possession of the current public key of the other. It may 
not be practical to require this assumption. 

A protocol using timestamps is provided in [DENN81]: 


1. AAS: ID, \lIDp 
2. ASA: E(PR,,, [ID 4 || PU; I T]) ll E(PRoss [Dz | PU; |I T]) 


3. A>B: — E(PR,, [ID lI PU, lI T]) I E(PRgss Dp | PUs | TJ) II 
E(PU,, E(PR,, [Ks ll T])) 


In this case, the central system is referred to as an authentication server (AS), 
because it is not actually responsible for secret-key distribution. Rather, the AS pro- 
vides public-key certificates. The session key is chosen and encrypted by A; hence, 
there is no risk of exposure by the AS. The timestamps protect against replays of 
compromised keys. 

This protocol is compact but, as before, requires the synchronization of clocks. 
Another approach, proposed by Woo and Lam [WOO92a], makes use of nonces. 
The protocol consists of the following steps. 


LA@KDC DM, \lID; 


2. KDC A: E(PRayns [Dg |! PU;]) 

3. ASB: E(PU,, [N, ll 1D4]) 

4. B>KDC: ID,|l IDgllE(PU syn, No) 

5. KDC>B: E(PRayths [[D.4ll PU,]) tl E(PU, E(PRauthy [Na |! Ky !! IDg])) 
6. BA: E(PU,, [E(PRauthe [(Nq ll Ky || LDg)]) |! Nol) 

7. AB: E(K,, Np) 


In step 1, A informs the KDC of its intention to establish a secure connection 
with B. The KDC returns to A a copy of B’s public-key certificate (step 2). Using B’s 
public key, A informs B of its desire to communicate and sends a nonce N, (step 3). In 
step 4, B asks the KDC for A’s public-key certificate and requests a session key; B 
includes A’s nonce so that the KDC can stamp the session key with that nonce. The 
nonce is protected using the KDC’s public key. In step 5, the KDC returns to B a copy 
of A’s public-key certificate, plus the information {N,, K,, [D}. This information basi- 
cally says that K, is a secret key generated by the KDC on behalf of B and tied to N,; 
the binding of K, and N, will assure A that K, is fresh. This triple is encrypted using 
the KDC’s private key to allow B to verify that the triple is in fact from the KDC. It is 
also encrypted using B’s public key so that no other entity may use the triple in an 
attempt to establish a fraudulent connection with A. In step 6, the triple {N,, K;, 1D g}, 
still encrypted with the KDC’s private key, is relayed to A, together with a nonce N, 
generated by B. All the foregoing are encrypted using A’s public key. A retrieves the 


15.4 / REMOTE USER AUTHENTICATION USING ASYMMETRIC ENCRYPTION 471 


session key K,, uses it to encrypt N,, and returns it to B. This last message assures B of 
A’s knowledge of the session key. 

This seems to be a secure protocol that takes into account the various attacks. 
However, the authors themselves spotted a flaw and submitted a revised version of 
the algorithm in [WOO92b]: 


1,A—>KDC:  ID,\lIDz 

2. KDC A: — E(PRanths [[Dg || PU;]) 

3. AB: E(PU,, [N, || [D4]) 

4.B—>KDC: = ID, Il IDg || E(PU gun» Na) 

5. KDC—B: — E(PRoautns [D4 || PU;]) || E(PUs, E(PRoutns [No | Ky I 


ID 4 || IDg])) 
6. BA: E(PU,, [E(PRauths [(No lI Ky || D4 || LDg) | N5])) 
7. AB: E(K,, Np) 


The identifier of A, JD ,, is added to the set of items encrypted with the KDC’s 
private key in steps 5 and 6. This binds the session key K, to the identities of the two 
parties that will be engaged in the session. This inclusion of JD, accounts for the fact 
that the nonce value N, is considered unique only among all nonces generated by A, 
not among all nonces generated by all parties. Thus, it is the pair {JD 4, N,} that 
uniquely identifies the connection request of A. 

In both this example and the protocols described earlier, protocols that 
appeared secure were revised after additional analysis. These examples highlight the 
difficulty of getting things right in the area of authentication. 


One-Way Authentication 


We have already presented public-key encryption approaches that are suited to 
electronic mail, including the straightforward encryption of the entire message for 
confidentiality (Figure 12.1b), authentication (Figure 12.1c), or both (Figure 12.1d). 
These approaches require that either the sender know the recipient’s public key 
(confidentiality), the recipient know the sender’s public key (authentication), or 
both (confidentiality plus authentication). In addition, the public-key algorithm 
must be applied once or twice to what may be a long message. 

If confidentiality is the primary concern, then the following may be more 
efficient: 


AB: E(PU,, K,||E(K, ) 


In this case, the message is encrypted with a one-time secret key. A also encrypts this 
one-time key with B’s public key. Only B will be able to use the corresponding 
private key to recover the one-time key and then use that key to decrypt the mes- 
sage. This scheme is more efficient than simply encrypting the entire message with 
B’s public key. 

If authentication is the primary concern, then a digital signature may suffice, as 
was illustrated in Figure 13.2: 


A—B: M||E(PR,, H(M)) 
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This method guarantees that A cannot later deny having sent the message. 
However, this technique is open to another kind of fraud. Bob composes a message 
to his boss Alice that contains an idea that will save the company money. He 
appends his digital signature and sends it into the e-mail system. Eventually, the 
message will get delivered to Alice’s mailbox. But suppose that Max has heard of 
Bob’s idea and gains access to the mail queue before delivery. He finds Bob’s mes- 
sage, strips off his signature, appends his, and requeues the message to be delivered 
to Alice. Max gets credit for Bob’s idea. 

To counter such a scheme, both the message and signature can be encrypted 
with the recipient’s public key: 


AB: E(PU,,[M || E(PR,, H(M))]) 


The latter two schemes require that B know A’s public key and be convinced 
that it is timely. An effective way to provide this assurance is the digital certificate, 
described in Chapter 14. Now we have 


A—B: M1 E(PR,, H(M)) ll E(PR,s [T || 1D4 I PU,]) 


In addition to the message, A sends B the signature encrypted with A’s private 
key and A’s certificate encrypted with the private key of the authentication server. 
The recipient of the message first uses the certificate to obtain the sender’s public 
key and verify that it is authentic and then uses the public key to verify the message 
itself. If confidentiality is required, then the entire message can be encrypted with 
B’s public key. Alternatively, the entire message can be encrypted with a one-time 
secret key; the secret key is also transmitted, encrypted with B’s public key. This 
approach is explored in Chapter 18. 


15.5 FEDERATED IDENTITY MANAGEMENT 


Federated identity management is a relatively new concept dealing with the use of a 
common identity management scheme across multiple enterprises and numerous 
applications and supporting many thousands, even millions, of users. We begin our 
overview with a discussion of the concept of identity management and then examine 
federated identity management. 


Identity Management 


Identity management is a centralized, automated approach to provide enterprise- 
wide access to resources by employees and other authorized individuals. The focus 
of identity management is defining an identity for each user (human or process), 
associating attributes with the identity, and enforcing a means by which a user can 
verify identity. The central concept of an identity management system is the use of 
single sign-on (SSO). SSO enables a user to access all network resources after a sin- 
gle authentication. 

[PELT07] lists the following as the principal elements of an identity manage- 
ment system. 
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e Authentication: Confirmation that a user corresponds to the user name 
provided. 


e Authorization: Granting access to specific services and/or resources based on 
the authentication. 


e Accounting: A process for logging access and authorization. 
e Provisioning: The enrollment of users in the system. 
¢ Workflow automation: Movement of data in a business process. 


e Delegated administration: The use of role-based access control to grant 
permissions. 


e Password synchronization: Creating a process for single sign-on (SSO) or 
reduced sign-on (RSO). Single sign-on enables a user to access all network 
resources after a single authentication. RSO may involve multiple sign-ons but 
requires less user effort than if each resource and service maintained its own 
authentication facility. 


e Self-service password reset: Enables the user to modify his or her password. 


e Federation: A process where authentication and permission will be passed on 
from one system to another—usually across multiple enterprises, thereby 
reducing the number of authentications needed by the user. 


Note that Kerberos contains a number of the elements of an identity manage- 
ment system. 

Figure 15.3 [LINN06] illustrates entities and data flows in a generic identity 
management architecture. A principal is an identity holder. Typically, this is a human 
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Figure 15.3. Generic Identity Management Architecture 
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user that seeks access to resources and services on the network. User devices, agent 
processes, and server systems may also function as principals. Principals authenticate 
themselves to an identity provider. The identity provider associates authentication 
information with a principal, as well as attributes and one or more identifiers. 

Increasingly, digital identities incorporate attributes other than simply an identi- 
fier and authentication information (such as passwords and biometric information). 
An attribute service manages the creation and maintenance of such attributes. For 
example, a user needs to provide a shipping address each time an order is placed at a 
new Web merchant, and this information needs to be revised when the user moves. 
Identity management enables the user to provide this information once, so that it is 
maintained in a single place and released to data consumers in accordance with autho- 
rization and privacy policies. Users may create some of the attributes to be associated 
with their digital identity, such as an address. Administrators may also assign attrib- 
utes to users, such as roles, access permissions, and employee information. 

Data consumers are entities that obtain and employ data maintained and 
provided by identity and attribute providers, which are often used to support autho- 
rization decisions and to collect audit information. For example, a database server 
or file server is a data consumer that needs a client’s credentials so as to know what 
access to provide to that client. 


Identity Federation 


Identity federation is, in essence, an extension of identity management to multiple 
security domains. Such domains include autonomous internal business units, exter- 
nal business partners, and other third-party applications and services. The goal is to 
provide the sharing of digital identities so that a user can be authenticated a single 
time and then access applications and resources across multiple domains. Because 
these domains are relatively autonomous or independent, no centralized control is 
possible. Rather, the cooperating organizations must form a federation based on 
agreed standards and mutual levels of trust to securely share digital identities. 

Federated identity management refers to the agreements, standards, and tech- 
nologies that enable the portability of identities, identity attributes, and entitlements 
across multiple enterprises and numerous applications and supporting many thou- 
sands, even millions, of users. When multiple organizations implement interoperable 
federated identity schemes, an employee in one organization can use a single sign- 
on to access services across the federation with trust relationships associated with 
the identity. For example, an employee may log onto her corporate intranet and be 
authenticated to perform authorized functions and access authorized services on 
that intranet. The employee could then access their health benefits from an outside 
health-care provider without having to reauthenticate. 

Beyond SSO, federated identity management provides other capabilities. One 
is a Standardized means of representing attributes. Increasingly, digital identities 
incorporate attributes other than simply an identifier and authentication informa- 
tion (such as passwords and biometric information). Examples of attributes include 
account numbers, organizational roles, physical location, and file ownership. A user 
may have multiple identifiers; for example, each identifier may be associated with a 
unique role with its own access permissions. 
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Another key function of federated identity management is identity mapping. 
Different security domains may represent identities and attributes differently. 
Further, the amount of information associated with an individual in one domain 
may be more than is necessary in another domain. The federated identity manage- 
ment protocols map identities and attributes of a user in one domain to the require- 
ments of another domain. 

Figure 15.4 illustrates entities and data flows in a generic federated identity 
management architecture. 

The identity provider acquires attribute information through dialogue and pro- 
tocol exchanges with users and administrators. For example, a user needs to provide 
a shipping address each time an order is placed at a new Web merchant, and this 
information needs to be revised when the user moves. Identity management enables 
the user to provide this information once, so that it is maintained in a single place and 
released to data consumers in accordance with authorization and privacy policies. 

Service providers are entities that obtain and employ data maintained and 
provided by identity providers, often to support authorization decisions and to 
collect audit information. For example, a database server or file server is a data 
consumer that needs a client’s credentials so as to know what access to provide to 
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that client. A service provider can be in the same domain as the user and the identity 
provider. The power of this approach is for federated identity management, in which 
the service provider is in a different domain (e.g.,a vendor or supplier network). 


STANDARDS Federated identity management uses a number of standards as the 
building blocks for secure identity exchange across different domains or hetero- 
geneous systems. In essence, organizations issue some form of security tickets for 
their users that can be processed by cooperating partners. Identity federation 
standards are thus concerned with defining these tickets, in terms of content and 
format, providing protocols for exchanging tickets and performing a number of 
management tasks. These tasks include configuring systems to perform attribute 
transfers and identity mapping, and performing logging and auditing functions. 

The principal underlying standard for federated identity is the Security 
Assertion Markup Language (SAML), which defines the exchange of security infor- 
mation between online business partners. SAML conveys authentication informa- 
tion in the form of assertions about subjects. Assertions are statements about the 
subject issued by an authoritative entity. 

SAML is part of a broader collection of standards being issued by OASIS 
(Organization for the Advancement of Structured Information Standards) for feder- 
ated identity management. For example, WS-Federation enables browser-based 
federation; it relies on a security token service to broker trust of identities, attributes, 
and authentication between participating Web services. 

The challenge with federated identity management is to integrate multiple 
technologies, standards, and services to provide a secure, user-friendly utility. The 
key, as in most areas of security and networking, is the reliance on a few mature 
standards widely accepted by industry. Federated identity management seems to 
have reached this level of maturity. 


ExAmpLes To get some feel for the functionality of identity federation, we look at 
three scenarios, taken from [COMP06]. 

In the first scenario (Figure 15.5a), Workplace.com contracts with Health.com 
to provide employee health benefits. An employee uses a Web interface to sign on to 
Workplace.com and goes through an authentication procedure there. This enables 
the employee to access authorized services and resources at Workplace.com. When 
the employee clicks on a link to access health benefits, her browser is redirected to 
Health.com. At the same time, the Workplace.com software passes the user’s identi- 
fier to Health.com in a secure manner. The two organizations are part of a federation 
that cooperatively exchanges user identifiers. Health.com maintains user identities 
for every employee at Workplace.com and associates with each identity health- 
benefits information and access rights. In this example, the linkage between the two 
companies is based on account information and user participation is browser based. 

Figure 15.5b shows a second type of browser-based scheme. PartsSupplier.com 
is a regular supplier of parts to Workplace.com. In this case, a role-based access- 
control (RBAC) scheme is used for access to information. An engineer of 
Workplace.com authenticates at the employee portal at Workplace.com and clicks on 
a link to access information at PartsSupplier.com. Because the user is authenticated 
in the role of an engineer, he is taken to the technical documentation and trou- 
bleshooting portion of PartsSupplier.com’s Web site without having to sign on. 
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Similarly, an employee in a purchasing role signs on at Workplace.com and is 
authorized, in that role, to place purchases at PartsSupplier.com without having to 
authenticate to PartsSupplier.com. For this scenario, PartsSupplier.com does not 
have identity information for individual employees at Workplace.com. Rather, the 
linkage between the two federated partners is in terms of roles. 

The scenario illustrated in Figure 15.5c can be referred to as document based 
rather than browser based. In this third example, Workplace.com has a purchasing 
agreement with PinSupplies.com, and PinSupplies.com has a business relationship 
with E-Ship.com. An employee of WorkPlace.com signs on and is authenticated to 
make purchases. The employee goes to a procurement application that provides a list 
of WorkPlace.com’s suppliers and the parts that can be ordered. The user clicks on 
the PinSupplies button and is presented with a purchase order Web page (HTML 
page). The employee fills out the form and clicks the submit button. The procurement 
application generates an XML/SOAP document that it inserts into the envelope 
body of an XML-based message. The procurement application then inserts the user’s 
credentials in the envelope header of the message, together with Workplace.com’s 
organizational identity. The procurement application posts the message to the 
PinSupplies.com’s purchasing Web service. This service authenticates the incoming 
message and processes the request. The purchasing Web service then sends a 
SOAP message to its shipping partner to fulfill the order. The message includes a 
PinSupplies.com security token in the envelope header and the list of items to be 
shipped as well as the end user’s shipping information in the envelope body. The ship- 
ping Web service authenticates the request and processes the shipment order. 


15.6 RECOMMENDED READING AND WEB SITES 


A painless way to get a grasp of Kerberos concepts is found in [BRYA88]. One of the best treat- 
ments of Kerberos is [KOHL94]. [TUNG99] describes Kerberos from a user’s point of view. 

[SHIM0S5] provides a brief overview of federated identity management and examines 
one approach to standardization. [BHATO7] describes an integrated approach to federated 
identity management coupled with management of access control privileges. 


BHATO07 Bhatti, R.; Bertino, E.; and Ghafoor, A. “An Integrated Approach to Federated 
Identity and Privilege Management in Open Systems.” Communications of the 
ACM, February 2007. 

BRYA88 Bryant, W. Designing an Authentication System: A Dialogue in Four Scenes. 
Project Athena document, February 1988. Available at http://web.mit.edu/kerberos/ 
www/dialogue.html. 


KOHL94 Kohl, J.; Neuman, B.; and Ts’o, T. “The Evolution of the Kerberos 


Authentication Service.” in Brazier, F, and Johansen, D. Distributed Open Systems. 
Los Alamitos, CA: IEEE Computer Society Press, 1994. Available at 
http://web.mit.edu/kerberos/www/papers.html. 

SHIMO05 Shim, S.; Bhalla, G.; and Pendyala, V. “Federated Identity Management.” 
Computer, December 2005. 

TUNG99 Tung, B. Kerberos: A Network Authentication System. Reading, MA: Addison- 
Wesley, 1999. 
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Recommended Web Sites: 


e MIT Kerberos Site: Information about Kerberos, including the FAQ, papers and 
documents, and pointers to commercial product sites. 


e MIT Kerberos Consortium: Created to establish Kerberos as the universal authentica- 
tion platform for the world’s computer networks. 


e USCAISI Kerberos Page: Another good source of Kerberos material. 


e Kerberos Working Group: IETF group developing standards based on Kerberos. 


15.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


authentication Kerberos realm realm 
authentication SS mutual authentication replay attack 
federated identity nonce suppress-replay attack 


Seaauapeuicut one-way authentication ticket 
identity management propagating cipher block ticket-granting server (TGS) 
Kerberos chaining (PCBC) mode timestamp 


Review Questions 


15.1 Give examples of replay attacks. 
15.2 List three general approaches to dealing with replay attacks. 
15.3. What is a suppress-replay attack? 
15.4 What problem was Kerberos designed to address? 
15.5 What are three threats associated with user authentication over a network or 
Internet? 
15.6 List three approaches to secure user authentication in a distributed environment. 
15.7 What four requirements were defined for Kerberos? 
15.8 What entities constitute a full-service Kerberos environment? 
15.9 In the context of Kerberos, what is a realm? 
15.10 What are the principal differences between version 4 and version 5 of Kerberos? 


Problems 


15.1 In Section 15.4, we outlined the public-key scheme proposed in [WOO92a] for the 
distribution of secret keys. The revised version includes JD, in steps 5 and 6. What 
attack, specifically, is countered by this revision? 

15.2. The protocol referred to in Problem 15.1 can be reduced from seven steps to five, hav- 
ing the following sequence: 

1. AB: 
2. A—>KDC: 
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KDC —B: 
BA: 
AB: 


ew 


Show the message transmitted at each step. Hint: The final message in this protocol is 

the same as the final message in the original protocol. 

Reference the suppress-replay attack described in Section 15.2 to answer the 

following. 

a. Give an example of an attack when a party’s clock is ahead of that of the KDC. 

b. Give an example of an attack when a party’s clock is ahead of that of another 
party. 

There are three typical ways to use nonces as challenges. Suppose N, is a nonce gen- 

erated by A, A and B share key K, and f() is a function (such as an increment). The 

three usages are 


Usage 1 Usage 2 Usage 3 
(1) A>B: N, (1) A>B: E(K,N,) | (1) AB: E(K,N,) 
(2) B> A: E(K,N,) | (2) BA: N, (2) B> A: E(K, f(N,)) 


Describe situations for which each usage is appropriate. 
Show that a random error in one block of ciphertext is propagated to all subsequent 
blocks of plaintext in PCBC mode (See Figure 15.7 in Appendix 15A). 
Suppose that, in PCBC mode, blocks C; and C;,; are interchanged during transmis- 
sion. Show that this affects only the decrypted blocks P; and P;,, but not subsequent 
blocks. 
In addition to providing a standard for public-key certificate formats, X.509 specifies 
an authentication protocol. The original version of X.509 contains a security flaw. The 
essence of the protocol is as follows. 

AB: A {t,, ra, ID p} 

B-A: B {tg, rg, 1D 4, ra} 

AB: A {rp} 
where ft, and fg are timestamps, r, and rg are nonces and the notation X {Y} indicates 
that the message Y is transmitted, encrypted, and signed by X. 

The text of X.509 states that checking timestamps t, and fg is optional for 
three-way authentication. But consider the following example: Suppose A and B have 
used the preceding protocol on some previous occasion, and that opponent C has 
intercepted the preceding three messages. In addition, suppose that timestamps are 
not used and are all set to 0. Finally, suppose C wishes to impersonate A to B. C ini- 
tially sends the first captured message to B: 

C—B: A {0,7r4, ID} 
B responds, thinking it is talking to A but is actually talking to C: 

B>C: B {0,rz, ID, ra} 

C meanwhile causes A to initiate authentication with C by some means. As a result, A 
sends C the following: 

A>C: A {0,1r4, IDc} 
C responds to A using the same nonce provided to C by B: 

CA: C{0, rg, ID,, 14} 

A responds with 

A>C: A {rz} 
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This is exactly what C needs to convince B that it is talking to A, so C now repeats the 
incoming message back out to B. 
C—B: A {rp} 
So B will believe it is talking to A whereas it is actually talking to C. Suggest a simple 
solution to this problem that does not involve the use of timestamps. 
15.8 Consider a one-way authentication technique based on asymmetric encryption: 
AB: ID, 
BA: R, 
AB: E(PR,, R) 
a. Explain the protocol. 
b. What type of attack is this protocol susceptible to? 
15.9 Consider a one-way authentication technique based on asymmetric encryption: 
AB: ID, 
BA: E(PU,, R2) 
AB: R, 
a. Explain the protocol. 
b. What type of attack is this protocol susceptible to? 
15.10 In Kerberos, when Bob receives a Ticket from Alice, how does he know it is genuine? 
15.11 In Kerberos, when Bob receives a Ticket from Alice, how does he know it came from Alice? 
15.12 In Kerberos, when Alice receives a reply, how does she know it came from Bob (that 
it’s not a replay of an earlier message from Bob)? 
15.13. In Kerberos, what does the Ticket contain that allows Alice and Bob to talk 
securely? 


APPENDIX 15A KERBEROS ENCRYPTION TECHNIQUES 


Kerberos includes an encryption library that supports various encryption-related 
operations. These were included in the Kerberos version 5 specification and are 
common in commercial implementations. In February 2005, IETF issued RFCs 3961 
and 3962, which expand the options of cryptographic techniques. In this appendix, 
we describe the original techniques. 


Password-to-Key Transformation 


In Kerberos, passwords are limited to the use of the characters that can be repre- 
sented in a 7-bit ASCII format. This password, of arbitrary length, is converted into 
an encryption key that is stored in the Kerberos database. Figure 15.6 illustrates the 
procedure. 

First, the character string, s,is packed into a bit string, b, such that the first charac- 
ter is stored in the first 7 bits, the second character in the second 7 bits, and so on. This 
can be expressed as 


b[0] = _ bit 0 of s[0] 
b[6] = bit 6 ofs[0] 
b[7] = _ bit Oofs[1] 


b[7i + m] = bitmofs[]] O=m=6 
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Figure 15.6 Generation of Encryption Key from Password 


Next, the bit string is compacted to 56 bits by aligning the bits in “fanfold” fash- 
ion and performing a bitwise XOR. For example, if the bit string is of length 59, then 


b[55] = —_-b[55] @ b[S6] 
b[54] = — b[54] @ b[S7] 
b[53] = —_-b[53] @ b[S8] 


This creates a 56-bit DES key. To conform to the expected 64-bit key format, the 
string is treated as a sequence of eight 7-bit blocks and is mapped into eight 8-bit 
blocks to form an input key K,,,. 

Finally, the original password is encrypted using the cipher block chaining 
(CBC) mode of DES with key K,,,. The last 64-bit block returned from this process, 
known as the CBC checksum, is the output key associated with this password. 

The entire algorithm can be viewed as a hash function that maps an arbitrary 
password into a 64-bit hash code. 
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Propagating Cipher Block Chaining Mode 


Recall from Chapter 6 that, in the CBC mode of DES, the input to the DES algo- 
rithm at each stage consists of the XOR of the current plaintext block and the pre- 
ceding ciphertext block with the same key used for each block (Figure 6.4). The 
advantage of this mode over the electronic codebook (ECB) mode, in which each 
plaintext block is independently encrypted, is this: With CBC, the same plaintext 
block produces different ciphertext blocks if repeated. 

CBC has the property that if an error occurs in transmission of ciphertext 
block C;, then this error propagates to the recovered plaintext blocks P; and P;,. 

Version 4 of Kerberos uses an extension to CBC called the propagating CBC 
(PCBC) mode [MEYE82]. This mode has the property that an error in one cipher- 
text block is propagated to all subsequent decrypted blocks of the message, render- 
ing each block useless. Thus, data encryption and integrity are combined in one 
operation. (For an exception, see Problem 15.6). 

PCBC is illustrated in Figure 15.7. In this scheme, the input to the encryption 
algorithm is the XOR of the current plaintext block, the preceding cipher text block, 
and the preceding plaintext block: 


C, = E(K, [C,-1 (>) ome ©) P,,]) 
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Figure 15.7 Propagating Cipher Block Chaining (PCBC) Mode 
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On decryption, each ciphertext block is passed through the decryption algo- 
rithm. Then the output is XORed with the preceding ciphertext block and the pre- 
ceding plaintext block. We can demonstrate that this scheme works, as follows. 


D(K, C,) = D(K, E(K, [C,-1 © Pn-1 ® Pnl)) 
D(K, iy) = Ch-1 ©) Pr-1 ©) Py 
Ch-1 ) Boat ) D(K, Cy = Py, 
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Use your mentality 
Wake up to reality 


—From the song, “Vve Got You Under My Skin” by Cole Porter 


KEY POINTS 


® Secure Socket Layer (SSL) provides security services between TCP and 
applications that use TCP. The Internet standard version is called Transport 
Layer Service (TLS). 


® SSL/TLS provides confidentiality using symmetric encryption and message 
integrity using a message authentication code. 

® SSL/TLS includes protocol mechanisms to enable two TCP users to deter- 
mine the security mechanisms and services they will use. 

© HTTPS (HTTP over SSL) refers to the combination of HTTP and SSL to 
implement secure communication between a Web browser and a Web server. 

® Secure Shell (SSH) provides secure remote logon and other secure 
client/server facilities. 


Virtually all businesses, most government agencies, and many individuals now have 
Web sites. The number of individuals and companies with Internet access is expanding 
rapidly and all of these have graphical Web browsers. As a result, businesses are enthu- 
siastic about setting up facilities on the Web for electronic commerce. But the reality is 
that the Internet and the Web are extremely vulnerable to compromises of various 
sorts. As businesses wake up to this reality, the demand for secure Web services grows. 

The topic of Web security is a broad one and can easily fill a book. In this 
chapter, we begin with a discussion of the general requirements for Web security 
and then focus on three standardized schemes that are becoming increasingly 
important as part of Web commerce and that focus on security at the transport 
layer: SSL/TLS, HTTPS, and SSH. 


16.1 WEB SECURITY CONSIDERATIONS 


The World Wide Web is fundamentally a client/server application running over the 
Internet and TCP/IP intranets. As such, the security tools and approaches discussed 
so far in this book are relevant to the issue of Web security. But, as pointed out in 
[GARF02], the Web presents new challenges not generally appreciated in the con- 
text of computer and network security. 


e The Internet is two-way. Unlike traditional publishing environments—even 
electronic publishing systems involving teletext, voice response, or fax-back— 
the Web is vulnerable to attacks on the Web servers over the Internet. 
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e The Web is increasingly serving as a highly visible outlet for corporate and 
product information and as the platform for business transactions. Reputations 
can be damaged and money can be lost if the Web servers are subverted. 


e Although Web browsers are very easy to use, Web servers are relatively easy 
to configure and manage, and Web content is increasingly easy to develop, the 
underlying software is extraordinarily complex. This complex software may 
hide many potential security flaws. The short history of the Web is filled with 
examples of new and upgraded systems, properly installed, that are vulnerable 
to a variety of security attacks. 


e A Web server can be exploited as a launching pad into the corporation’s or 
agency’s entire computer complex. Once the Web server is subverted, an 
attacker may be able to gain access to data and systems not part of the Web 
itself but connected to the server at the local site. 


e Casual and untrained (in security matters) users are common clients for 
Web-based services. Such users are not necessarily aware of the security 
risks that exist and do not have the tools or knowledge to take effective 
countermeasures. 


Web Security Threats 


Table 16.1 provides a summary of the types of security threats faced when using the 
Web. One way to group these threats is in terms of passive and active attacks. 
Passive attacks include eavesdropping on network traffic between browser and 
server and gaining access to information on a Web site that is supposed to be 
restricted. Active attacks include impersonating another user, altering messages in 
transit between client and server, and altering information on a Web site. 

Another way to classify Web security threats is in terms of the location of the 
threat: Web server, Web browser, and network traffic between browser and server. 
Issues of server and browser security fall into the category of computer system secu- 
rity; Part Four of this book addresses the issue of system security in general but is 
also applicable to Web system security. Issues of traffic security fall into the category 
of network security and are addressed in this chapter. 


Web Traffic Security Approaches 


A number of approaches to providing Web security are possible. The various 
approaches that have been considered are similar in the services they provide and, 
to some extent, in the mechanisms that they use, but they differ with respect to their 
scope of applicability and their relative location within the TCP/IP protocol stack. 

Figure 16.1 illustrates this difference. One way to provide Web security is to 
use IP security (IPsec) (Figure 16.1a). The advantage of using IPsec is that it is trans- 
parent to end users and applications and provides a general-purpose solution. 
Furthermore, IPsec includes a filtering capability so that only selected traffic need 
incur the overhead of IPsec processing. 

Another relatively general-purpose solution is to implement security just 
above TCP (Figure 16.1b). The foremost example of this approach is the Secure 
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» 16.1 A Comparison of Threats on the Web 


Threats Consequences Countermeasures 


Integrity Modification of user data Loss of information Cryptographic 
: ; : checksums 

Trojan horse browser Compromise of machine 
Modification of memory Vulnerabilty to all other 


Modification of message threats 
traffic in transit 


Confidentiality Eavesdropping on the net Loss of information Encryption, Web 


Theft of info from server Loss of privacy aa 
Theft of data from client 


Info about network 
configuration 


Info about which client 
talks to server 


Denial of Killing of user threads Disruptive Difficult to prevent 


Service Flooding machine with Annoying 


bogus requests Prevent user from getting 


Filling up disk or memory work done 


Isolating machine by DNS 
attacks 


Authentication Impersonation of legitimate Misrepresentation of user Cryptographic 


Users: Belief that false information SEEMS 


Data forgery is valid 


Sockets Layer (SSL) and the follow-on Internet standard known as Transport Layer 
Security (TLS). At this level, there are two implementation choices. For full general- 
ity, SSL (or TLS) could be provided as part of the underlying protocol suite and 
therefore be transparent to applications. Alternatively, SSL can be embedded in 
specific packages. For example, Netscape and Microsoft Explorer browsers come 
equipped with SSL, and most Web servers have implemented the protocol. 
Application-specific security services are embedded within the particular appli- 
cation. Figure 16.1c shows examples of this architecture. The advantage of this 
approach is that the service can be tailored to the specific needs of a given application. 


SMTP Kerberos} SMTP | HTTP 


(a) Network level (b) Transport level (c) Application level 


TCP 


Figure 16.1 Relative Location of Security Facilities in the TCP/IP Protocol Stack 
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16.2 SECURE SOCKET LAYER AND TRANSPORT 


LAYER SECURITY 


Netscape originated SSL. Version 3 of the protocol was designed with public review 
and input from industry and was published as an Internet draft document. 
Subsequently, when a consensus was reached to submit the protocol for Internet 
standardization, the TLS working group was formed within IETF to develop a com- 
mon standard. This first published version of TLS can be viewed as essentially an 
SSLv3.1 and is very close to and backward compatible with SSLv3. 

This section is devoted to a discussion of SSLv3. In the next section, the principal 
differences between SSLv3 and TLS are described. 


SSL Architecture 


SSL is designed to make use of TCP to provide a reliable end-to-end secure service. 
SSL is not a single protocol but rather two layers of protocols, as illustrated in 
Figure 16.2. 

The SSL Record Protocol provides basic security services to various higher- 
layer protocols. In particular, the Hypertext Transfer Protocol (HTTP), which pro- 
vides the transfer service for Web client/server interaction, can operate on top of 
SSL. Three higher-layer protocols are defined as part of SSL: the Handshake 
Protocol, The Change Cipher Spec Protocol, and the Alert Protocol. These SSL-spe- 
cific protocols are used in the management of SSL exchanges and are examined 
later in this section. 

Two important SSL concepts are the SSL session and the SSL connection, 
which are defined in the specification as follows. 


e Connection: A connection is a transport (in the OSI layering model defini- 
tion) that provides a suitable type of service. For SSL, such connections are 
peer-to-peer relationships. The connections are transient. Every connection is 
associated with one session. 


e Session: An SSL session is an association between a client and a server. Sessions 
are created by the Handshake Protocol. Sessions define a set of cryptographic 


SSL SSL Change 
Handshake | Cipher Spec | SS! Aleit HTTP 
Protocol Protocol oe 


SSL Record Protocol 


Figure 16.2 SSL Protocol Stack 
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security parameters which can be shared among multiple connections. Sessions 
are used to avoid the expensive negotiation of new security parameters for 
each connection. 


Between any pair of parties (applications such as HTTP on client and server), 
there may be multiple secure connections. In theory, there may also be multiple 
simultaneous sessions between parties, but this feature is not used in practice. 

There are a number of states associated with each session. Once a session is 
established, there is a current operating state for both read and write (i.e., receive 
and send). In addition, during the Handshake Protocol, pending read and write 
states are created. Upon successful conclusion of the Handshake Protocol, the 
pending states become the current states. 

A session state is defined by the following parameters. 


e Session identifier: An arbitrary byte sequence chosen by the server to identify 
an active or resumable session state. 


e Peer certificate: An X509.v3 certificate of the peer. This element of the state 
may be null. 

e Compression method: The algorithm used to compress data prior to encryption. 

e Cipher spec: Specifies the bulk data encryption algorithm (such as null, AES, 


etc.) and a hash algorithm (such as MD5 or SHA-1) used for MAC calculation. 
It also defines cryptographic attributes such as the hash_size. 


e Master secret: 48-byte secret shared between the client and server. 


e Isresumable: A flag indicating whether the session can be used to initiate new 
connections. 


A connection state is defined by the following parameters. 


e Server and client random: Byte sequences that are chosen by the server and 
client for each connection. 


e Server write MAC secret: The secret key used in MAC operations on data 
sent by the server. 


e Client write MAC secret: The secret key used in MAC operations on data 
sent by the client. 


e Server write key: The secret encryption key for data encrypted by the server 
and decrypted by the client. 


e Client write key: The symmetric encryption key for data encrypted by the 
client and decrypted by the server. 


e Initialization vectors: When a block cipher in CBC mode is used, an initializa- 
tion vector (IV) is maintained for each key. This field is first initialized by the 
SSL Handshake Protocol. Thereafter, the final ciphertext block from each 
record is preserved for use as the IV with the following record. 


e Sequence numbers: Each party maintains separate sequence numbers for 
transmitted and received messages for each connection. When a party sends or 
receives a change cipher spec message, the appropriate sequence number is set 
to zero. Sequence numbers may not exceed 21, 
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SSL Record Protocol 


The SSL Record Protocol provides two services for SSL connections: 


e Confidentiality: The Handshake Protocol defines a shared secret key that is 
used for conventional encryption of SSL payloads. 


e Message Integrity: The Handshake Protocol also defines a shared secret key 
that is used to form a message authentication code (MAC). 


Figure 16.3 indicates the overall operation of the SSL Record Protocol. The 
Record Protocol takes an application message to be transmitted, fragments the data 
into manageable blocks, optionally compresses the data, applies a MAC, encrypts, 
adds a header, and transmits the resulting unit in a TCP segment. Received data are 
decrypted, verified, decompressed, and reassembled before being delivered to 
higher-level users. 

The first step is fragmentation. Each upper-layer message is fragmented 
into blocks of 2'4 bytes (16384 bytes) or less. Next, compression is optionally 
applied. Compression must be lossless and may not increase the content 
length by more than 1024 bytes.'In SSLv3 (as well as the current version of TLS), 
no compression algorithm is specified, so the default compression algorithm 
is null. 

The next step in processing is to compute a message authentication code over 
the compressed data. For this purpose, a shared secret key is used. The calculation is 
defined as 


Application data 
Fragment 
Compress 
Add MAC 


Encrypt 


Append SSL 
record header 


Figure 16.3 SSL Record Protocol Operation 


'Of course, one hopes that compression shrinks rather than expands the data. However, for very short 
blocks, it is possible, because of formatting conventions, that the compression algorithm will actually 
provide output that is longer than the input. 
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hash(MAC_write_secret || pad_2|| 
hash(MAC_write_secret || pad_1||seq_num || 
SSLCompressed.type || SSLCompressed.length || 
SSLCompressed. fragment )) 


where 
| = concatenation 
MAC_write_secret = shared secret key 
hash = cryptographic hash algorithm; either 
MDS or SHA-1 
pad_1 = the byte 0x36 (0011 0110) repeated 


48 times (384 bits) for MD5 and 40 
times (320 bits) for SHA-1 

pad_2 = the byte 0x5C (0101 1100) repeated 48 
times for MD5 and 40 times for SHA-1 


seq_num = the sequence number for this message 

SSLCompressed. type = the higher-level protocol used to process 
this fragment 

SSLCompressed.length = the length of the compressed fragment 


SSLCompressed.fragment = the compressed fragment (if compression 
is not used, this is the plaintext fragment) 


Note that this is very similar to the HMAC algorithm defined in Chapter 12. The 
difference is that the two pads are concatenated in SSLv3 and are XORed in HMAC. 
The SSLv3 MAC algorithm is based on the original Internet draft for HMAC, which 
used concatenation. The final version of HMAC (defined in RFC 2104) uses the XOR. 

Next, the compressed message plus the MAC are encrypted using symmetric 
encryption. Encryption may not increase the content length by more than 1024 
bytes, so that the total length may not exceed 2'4 + 2048. The following encryption 
algorithms are permitted: 


Block Cipher Stream Cipher 
Algorithm Key Size Algorithm Key Size 
AES 128, 256 RC4-40 40 
IDEA 128 RC4-128 128 
RC2-40 40 
DES-40 40 
DES 56 
3DES 168 
Fortezza 80 


Fortezza can be used in a smart card encryption scheme. 

For stream encryption, the compressed message plus the MAC are encrypted. 
Note that the MAC is computed before encryption takes place and that the MAC 
is then encrypted along with the plaintext or compressed plaintext. 

For block encryption, padding may be added after the MAC prior to encryp- 
tion. The padding is in the form of a number of padding bytes followed by a one-byte 
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indication of the length of the padding. The total amount of padding is the smallest 
amount such that the total size of the data to be encrypted (plaintext plus MAC plus 
padding) is a multiple of the cipher’s block length. An example is a plaintext (or 
compressed text if compression is used) of 58 bytes, with a MAC of 20 bytes (using 
SHA-1), that is encrypted using a block length of 8 bytes (e.g., DES). With the 
padding-length byte, this yields a total of 79 bytes. To make the total an integer 
multiple of 8, one byte of padding is added. 

The final step of SSL Record Protocol processing is to prepare a header 
consisting of the following fields: 


e Content Type (8 bits): The higher-layer protocol used to process the enclosed 
fragment. 


e Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the 
value is 3. 


e Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is 0. 


e Compressed Length (16 bits): The length in bytes of the plaintext fragment (or 
compressed fragment if compression is used). The maximum value is 2'4+2048. 


The content types that have been defined are change_cipher_spec, 
alert, handshake, and application_data. The first three are the SSL-specific 
protocols, discussed next. Note that no distinction is made among the various appli- 
cations (e.g., HTTP) that might use SSL; the content of the data created by such 
applications is opaque to SSL. 

Figure 16.4 illustrates the SSL record format. 


Change Cipher Spec Protocol 


The Change Cipher Spec Protocol is one of the three SSL-specific protocols that use 
the SSL Record Protocol, and it is the simplest. This protocol consists of a single 
message (Figure 16.5a), which consists of a single byte with the value 1. The sole pur- 
pose of this message is to cause the pending state to be copied into the current state, 
which updates the cipher suite to be used on this connection. 


Plaintext 
(optionally 
compressed) 


Encrypted 


x MAC (0, 16, or 20 bytes) 
OO ODO OO7—OXN 


QL 


Figure 16.4 SSL Record Format 
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1 byte 1 byte 3 bytes = 0 bytes 


[=| 


(a) Change Cipher Spec Protocol (c) Handshake Protocol 


1 byte 


Level 


1 byte = | byte 


Opaque content 


(b) Alert Protocol (d) Other Upper-Layer Protocol (e.g., HTTP) 


Figure 16.5 


SSL Record Protocl Payload 


Alert Protocol 


The Alert Protocol is used to convey SSL-related alerts to the peer entity. As with 
other applications that use SSL, alert messages are compressed and encrypted, as 
specified by the current state. 


Each message in this protocol consists of two bytes (Figure 16.5b). The first 


byte takes the value warning (1) or fatal (2) to convey the severity of the message. If 
the level is fatal, SSL immediately terminates the connection. Other connections on 
the same session may continue, but no new connections on this session may be 
established. The second byte contains a code that indicates the specific alert. First, 
we list those alerts that are always fatal (definitions from the SSL specification): 


unexpected_message: An inappropriate message was received. 
bad_record_mac: An incorrect MAC was received. 


decompression_failure: The decompression function received improper 
input (e.g., unable to decompress or decompress to greater than maximum 
allowable length). 


handshake_failure: Sender was unable to negotiate an acceptable set of 
security parameters given the options available. 


illegal_parameter: A field in a handshake message was out of range or 
inconsistent with other fields. 


The remaining alerts are the following. 


close_notify: Notifies the recipient that the sender will not send any 
more messages on this connection. Each party is required to send a 
close_notify alert before closing the write side of a connection. 


no_certificate: May be sent in response to a certificate request if no 
appropriate certificate is available. 


bad_certificate: A received certificate was corrupt (e.g., contained a 
signature that did not verify). 


unsupported_certificate: The type of the received certificate is not 
supported. 


certificate_revoked: A certificate has been revoked by its signer. 


certificate_expired: A certificate has expired. 
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° certificate_unknown: Some other unspecified issue arose in processing 
the certificate, rendering it unacceptable. 


Handshake Protocol 


The most complex part of SSL is the Handshake Protocol. This protocol allows the 
server and client to authenticate each other and to negotiate an encryption and 
MAC algorithm and cryptographic keys to be used to protect data sent in an SSL 
record. The Handshake Protocol is used before any application data is transmitted. 

The Handshake Protocol consists of a series of messages exchanged by client 
and server. All of these have the format shown in Figure 16.5c. Each message has 
three fields: 


e Type (1 byte): Indicates one of 10 messages. Table 16.2 lists the defined 
message types. 

e Length (3 bytes): The length of the message in bytes. 

e Content ( = O bytes): The parameters associated with this message; these are 
listed in Table 16.2. 


Figure 16.6 shows the initial exchange needed to establish a logical connection 
between client and server. The exchange can be viewed as having four phases. 


PHASE 1, ESTABLISH SECURITY CAPABILITIES This phase is used to initiate a logical 
connection and to establish the security capabilities that will be associated with it. 
The exchange is initiated by the client, which sends a client _he11o message with 
the following parameters: 


e Version: The highest SSL version understood by the client. 


e Random: A client-generated random structure consisting of a 32-bit timestamp 
and 28 bytes generated by a secure random number generator. These values 
serve as nonces and are used during key exchange to prevent replay attacks. 

Table 16.2 SSL Handshake Protocol Message Types 


Parameters 


Message Type 


hello_request null 


client hello version, random, session id, cipher suite, compression method 


server hello version, random, session id, cipher suite, compression method 


certificate chain of X.509v3 certificates 


server_key exchange 
certificate_request 
server_done 
certificate_verify 
client_key exchange 


finished 


parameters, signature 
type, authorities 

null 

signature 
parameters, signature 


hash value 
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Handshake Protocol Action 


Server 


Phase 1 

Establish security capabilities, including 
protocol version, session ID, cipher suite, 
compression method, and initial random 
numbers. 


Phase 2 

Server may send certificate, key exchange, 
and request certificate. Server signals end 
of hello message phase. 


Phase 3 

Client sends certificate if requested. Client 
sends key exchange. Client may send 
certificate verification. 


Phase 4 
Change cipher suite and finish 
handshake protocol. 


Note: Shaded transfers are 
optional or situation-dependent 
messages that are not always sent. 


e Session ID: A variable-length session identifier. A nonzero value indicates 
that the client wishes to update the parameters of an existing connection or to 
create a new connection on this session. A zero value indicates that the client 
wishes to establish a new connection on a new session. 


e CipherSuite: This is a list that contains the combinations of cryptographic 
algorithms supported by the client, in decreasing order of preference. Each 
element of the list (each cipher suite) defines both a key exchange algorithm 
and a CipherSpec; these are discussed subsequently. 


16.2 / SECURE SOCKET LAYER AND TRANSPORT LAYER SECURITY 497 


e Compression Method: This is a list of the compression methods the client 
supports. 


After sending the client_hello message, the client waits for the 
server_hello message, which contains the same parameters as the 
client_hello message. For the server_hello message, the following conven- 
tions apply. The Version field contains the lower of the versions suggested by the 
client and the highest supported by the server. The Random field is generated by 
the server and is independent of the client’s Random field. If the SessionID field of 
the client was nonzero, the same value is used by the server; otherwise the server’s 
SessionID field contains the value for a new session. The CipherSuite field contains 
the single cipher suite selected by the server from those proposed by the client. The 
Compression field contains the compression method selected by the server from 
those proposed by the client. 

The first element of the CipherSuite parameter is the key exchange method 
(i.e., the means by which the cryptographic keys for conventional encryption and 
MAC are exchanged). The following key exchange methods are supported. 


e RSA: The secret key is encrypted with the receiver’s RSA public key. A public- 
key certificate for the receiver’s key must be made available. 


Fixed Diffie-Hellman: This is a Diffie-Hellman key exchange in which the 
setver’s certificate contains the Diffie-Hellman public parameters signed by 
the certificate authority (CA). That is, the public-key certificate contains the 
Diffie-Hellman public-key parameters. The client provides its Diffie-Hellman 
public-key parameters either in a certificate, if client authentication is 
required, or in a key exchange message. This method results in a fixed secret 
key between two peers based on the Diffie-Hellman calculation using the 
fixed public keys. 


Ephemeral Diffie-Hellman: This technique is used to create ephemeral 
(temporary, one-time) secret keys. In this case, the Diffie-Hellman public 
keys are exchanged, signed using the sender’s private RSA or DSS key. 
The receiver can use the corresponding public key to verify the signature. 
Certificates are used to authenticate the public keys. This would appear to 
be the most secure of the three Diffie-Hellman options, because it results in a 
temporary, authenticated key. 


Anonymous Diffie-Hellman: The base Diffie-Hellman algorithm is used with 
no authentication. That is, each side sends its public Diffie-Hellman parameters 
to the other with no authentication. This approach is vulnerable to man-in-the- 
middle attacks, in which the attacker conducts anonymous Diffie-Hellman with 
both parties. 


Fortezza: The technique defined for the Fortezza scheme. 


Following the definition of a key exchange method is the CipherSpec, which 
includes the following fields. 


e CipherAlgorithm: Any of the algorithms mentioned earlier: RC4, RC2, DES, 
3DES, DES40, IDEA, or Fortezza 
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e MACAlgorithm: MD5 or SHA-1 
e CipherType: Stream or Block 


IsExportable: True or False 
HashSize: 0, 16 (for MDS), or 20 (for SHA-1) bytes 


e Key Material: A sequence of bytes that contain data used in generating the 
write keys 


e IV Size: The size of the Initialization Value for Cipher Block Chaining (CBC) 
encryption 


PHASE 2. SERVER AUTHENTICATION AND KEY EXCHANGE The server begins this phase 
by sending its certificate if it needs to be authenticated; the message contains one or 
a chain of X.509 certificates. The certificate message is required for any agreed-on 
key exchange method except anonymous Diffie-Hellman. Note that if fixed Diffie- 
Hellman is used, this certificate message functions as the server’s key exchange 
message because it contains the server’s public Diffie-Hellman parameters. 

Next, a server_key_exchange message may be sent if it is required. It 
is not required in two instances: (1) The server has sent a certificate with fixed 
Diffie-Hellman parameters or (2) a RSA key exchange is to be used. The 
server_key_exchange message is needed for the following: 


e Anonymous Diffie-Hellman: The message content consists of the two global 
Diffie-Hellman values (a prime number and a primitive root of that number) 
plus the server’s public Diffie-Hellman key (see Figure 10.1). 


e Ephemeral Diffie-Hellman: The message content includes the three Diffie- 
Hellman parameters provided for anonymous Diffie-Hellman plus a signature 
of those parameters. 


e RSA key exchange (in which the server is using RSA but has a signature-only 
RSA key): Accordingly, the client cannot simply send a secret key encrypted 
with the server’s public key. Instead, the server must create a temporary RSA 
public/private key pair and use the server_key_exchange message to send 
the public key. The message content includes the two parameters of the 
temporary RSA public key (exponent and modulus; see Figure 9.5) plus a 
signature of those parameters. 


e Fortezza 


Some further details about the signatures are warranted. As usual, a signature 
is created by taking the hash of a message and encrypting it with the sender’s private 
key. In this case, the hash is defined as 


hash(ClientHello.random || ServerHello.random || 
ServerParams) 


So the hash covers not only the Diffie-Hellman or RSA parameters but also the two 
nonces from the initial hello messages. This ensures against replay attacks and 
misrepresentation. In the case of a DSS signature, the hash is performed using the 
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SHA-1 algorithm. In the case of an RSA signature, both an MD5 and an SHA-1 
hash are calculated, and the concatenation of the two hashes (36 bytes) is encrypted 
with the server’s private key. 

Next, a nonanonymous server (server not using anonymous Diffie-Hellman) 
can request a certificate from the client. The certificate_request message 
includes two parameters: certificate_type and certificate_authorities. 
The certificate type indicates the public-key algorithm and its use: 


e RSA, signature only 
e DSS, signature only 


e RSA for fixed Diffie-Hellman; in this case the signature is used only for 
authentication, by sending a certificate signed with RSA 


e DSS for fixed Diffie-Hellman; again, used only for authentication 
e RSA for ephemeral Diffie-Hellman 

e DSS for ephemeral Diffie-Hellman 

e Fortezza 


The second parameter in the certificate_request message is a list of the 
distinguished names of acceptable certificate authorities. 

The final message in phase 2, and one that is always required, is the 
server_done message, which is sent by the server to indicate the end of the 
server hello and associated messages. After sending this message, the server will 
wait for a client response. This message has no parameters. 


PHASE 3. CLIENT AUTHENTICATION AND Key EXCHANGE Upon receipt of the 
server_done message, the client should verify that the server provided a valid 
certificate (if required) and check that the server_hel1o parameters are acceptable. 
If all is satisfactory, the client sends one or more messages back to the server. 

If the server has requested a certificate, the client begins this phase by sending 
a certificate message. If no suitable certificate is available, the client sends a 
no_certificate alert instead. 

Next is the client_key_exchange message, which must be sent in this 
phase. The content of the message depends on the type of key exchange, as follows. 


e RSA: The client generates a 48-byte pre-master secret and encrypts with the 
public key from the server’s certificate or temporary RSA key from a 
server_key_exchange message. Its use to compute a master secret is 
explained later. 


e Ephemeral or Anonymous Diffie-Hellman: The client’s public Diffie-Hellman 
parameters are sent. 


e Fixed Diffie-Hellman: The client’s public Diffie-Hellman parameters were 
sent in a certificate message, so the content of this message is null. 


e Fortezza: The client’s Fortezza parameters are sent. 
Finally, in this phase, the client may send a certificate_verify message 


to provide explicit verification of a client certificate. This message is only sent fol- 
lowing any client certificate that has signing capability (i.e., all certificates except 
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those containing fixed Diffie-Hellman parameters). This message signs a hash code 
based on the preceding messages, defined as 


CertificateVerify.signature.md5_hash= 


MD5(master_secret || pad_2 || MD5(handshake_messages || 
master_secret || pad_1)); 
CertificateVerify.signature.sha_hash= 
SHA(master_secret || pad_2 || SHA(handshake_messages || 
master_secret || pad_1)); 


where pad_1 and pad_2 are the values defined earlier for the MAC, 
handshake_messages refers to all Handshake Protocol messages sent or 
received starting at client_hello but not including this message, and 
master_secret is the calculated secret whose construction is explained later in 
this section. If the user’s private key is DSS, then it is used to encrypt the SHA-1 
hash. If the user’s private key is RSA, it is used to encrypt the concatenation of the 
MDS and SHA-1 hashes. In either case, the purpose is to verify the client’s owner- 
ship of the private key for the client certificate. Even if someone is misusing the 
client’s certificate, he or she would be unable to send this message. 


PHASE 4. FinisH This phase completes the setting up of a secure connection. The 
client sends a change_cipher_spec message and copies the pending CipherSpec 
into the current CipherSpec. Note that this message is not considered part of the 
Handshake Protocol but is sent using the Change Cipher Spec Protocol. The client 
then immediately sends the finished message under the new algorithms, keys, and 
secrets. The finished message verifies that the key exchange and authentication 
processes were successful. The content of the finished message is the concatenation of 
two hash values: 


MD5(master_secret || pad2 || MD5(handshake_messages || 
Sender || master_secret || pad1)) 

SHA(master_secret || pad2 || SHA(handshake_messages || 
Sender || master_secret || pad1)) 


where Sender is a code that identifies that the sender is the client and 
handshake_messages is all of the data from all handshake messages up to but 
not including this message. 

In response to these two messages, the server sends its own 
change_cipher_spec message, transfers the pending to the current CipherSpec, 
and sends its finished message. At this point, the handshake is complete and the 
client and server may begin to exchange application-layer data. 


Cryptographic Computations 


Two further items are of interest: (1) the creation of a shared master secret by means 
of the key exchange and (2) the generation of cryptographic parameters from the 
master secret. 
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MASTER SECRET CREATION The shared master secret is a one-time 48-byte value 
(384 bits) generated for this session by means of secure key exchange. The creation 
is in two stages. First, a pre_master_secret is exchanged. Second, the 
master_secret is calculated by both parties. For pre_master_secret 
exchange, there are two possibilities. 


e RSA: A 48-byte pre_master_secret is generated by the client, encrypted 
with the server’s public RSA key, and sent to the server. The server decrypts 
the ciphertext using its private key to recover the pre_master_secret. 

e Diffie-Hellman: Both client and server generate a Diffie-Hellman public key. 
After these are exchanged, each side performs the Diffie-Hellman calculation 
to create the shared pre_master_secret. 


Both sides now compute the master_secret as 


SHA('A' || 
ClientHello.random || 


master_secret = MD5(pre_master_secret | 
pre_master_secret | 
ServerHello.random) 
MD5(pre_master_secret || SHA('BB' || 
pre_master_secret || ClientHello.random || 
ServerHello.random)) || 
| 
| 
) 


MD5 (pre_master_secret SHA('CCC' || 
pre_master_secret || ClientHello.random || 
ServerHello.random)) 


where ClientHello.random and ServerHello.random are the two 
nonce values exchanged in the initial hello messages. 


GENERATION OF CRYPTOGRAPHIC PARAMETERS CipherSpecs require a client write 
MAC secret, a server write MAC secret, a client write key, a server write key, a client 
write IV, and a server write IV, which are generated from the master secret in that 
order. These parameters are generated from the master secret by hashing the master 
secret into a sequence of secure bytes of sufficient length for all needed parameters. 

The generation of the key material from the master secret uses the same format 
for generation of the master secret from the pre-master secret as 


key_block = MD5(master_secret || SHA('A' || master_secret || 
ServerHello.random || ClientHello.random)) || 
MD5(master_secret || SHA('BB' || master_secret || 
ServerHello.random || ClientHello.random)) || 
MD5(master_secret || SHA('CCC' || master_secret || 


ServerHello.random || ClientHello.random)) ||... 


until enough output has been generated. The result of this algorithmic structure is a 
pseudorandom function. We can view the master_secret as the pseudorandom 
seed value to the function. The client and server random numbers can be viewed as 
salt values to complicate cryptanalysis (see Chapter 20 for a discussion of the use of 
salt values). 
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16.3 TRANSPORT LAYER SECURITY 


TLS is an IETF standardization initiative whose goal is to produce an Internet 
standard version of SSL. TLS is defined as a Proposed Internet Standard in RFC 
5246. RFC 5246 is very similar to SSLv3. In this section, we highlight the 
differences. 


Version Number 


The TLS Record Format is the same as that of the SSL Record Format 
(Figure 16.4), and the fields in the header have the same meanings. The one differ- 
ence is in version values. For the current version of TLS, the major version is 3 and 
the minor version is 3. 


Message Authentication Code 


There are two differences between the SSLv3 and TLS MAC schemes: the actual 
algorithm and the scope of the MAC calculation. TLS makes use of the HMAC 
algorithm defined in RFC 2104. Recall from Chapter 12 that HMAC is defined as 


HMAC, (M) = H[(K* @ opad) ||H[ (K* @® ipad) ||) ] 


where 


= embedded hash function (for TLS, either MD5 or SHA-1) 


H 

M = message input to HMAC 

K* = secret key padded with zeros on the left so that the result is equal 
to the block length of the hash code (for MD5 and SHA-1, block 
length = 512 bits) 

ipad = 00110110 (36 in hexadecimal) repeated 64 times (512 bits) 

opad = 01011100 (SC in hexadecimal) repeated 64 times (512 bits) 


SSLv3 uses the same algorithm, except that the padding bytes are 
concatenated with the secret key rather than being XORed with the secret key 
padded to the block length. The level of security should be about the same in 
both cases. 

For TLS, the MAC calculation encompasses the fields indicated in the following 
expression: 


MAC (MAC_write_secret,seq_num || TLSCompressed.type || 
TLSCompressed.version || TLSCompressed.length || 
TLSCompressed. fragment) 


The MAC calculation covers all of the fields covered by the SSLv3 calculation, 
plus the field TLSCompressed.version, which is the version of the protocol 
being employed. 
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Pseudorandom Function 


TLS makes use of a pseudorandom function referred to as PRF to expand secrets 
into blocks of data for purposes of key generation or validation. The objective is to 
make use of a relatively small shared secret value but to generate longer blocks of 
data in a way that is secure from the kinds of attacks made on hash functions and 
MACs. The PRF is based on the data expansion function (Figure 16.7) given as 


P_hash(secret, seed) = HMAC_hash(secret,A(1) || seed) || 
HMAC_hash(secret, A(2) || seed) || 
HMAC_hash(secret, A(3) || seed) || 


where A() is defined as 


A(0) = seed 
A(i) = HMAC _hash(secret, A(i - 1)) 


Seed 


Secret 


Secret 


Length = hash size 


Figure 16.7. TLS Function P_hash(secret, seed) 
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The data expansion function makes use of the HMAC algorithm with either MD5 
or SHA-1 as the underlying hash function. As can be seen, P_hash can be 
iterated as many times as necessary to produce the required quantity of data. For 
example, if P_SHA-1 was used to generate 64 bytes of data, it would have to be 
iterated four times, producing 80 bytes of data of which the last 16 would be dis- 
carded. In this case, P_MD5 would also have to be iterated four times, producing 
exactly 64 bytes of data. Note that each iteration involves two executions of 
HMAC—each of which in turn involves two executions of the underlying hash 
algorithm. 

To make PRF as secure as possible, it uses two hash algorithms in a way 
that should guarantee its security if either algorithm remains secure. PRF is 
defined as 


PRF (secret, label, seed) = P_hash(S1,label || seed) 


PRF takes as input a secret value, an identifying label, and a seed value and 
produces an output of arbitrary length. 


Alert Codes 


TLS supports all of the alert codes defined in SSLv3 with the exception of 
no_certificate. A number of additional codes are defined in TLS; of these, the 
following are always fatal. 


° record_overflow: A TLS record was received with a payload (ciphertext) 
whose length exceeds 2!4+2048 bytes, or the ciphertext decrypted to a length 
of greater than 2'4+1024 bytes. 


e unknown_ca: A valid certificate chain or partial chain was received, but the 
certificate was not accepted because the CA certificate could not be located or 
could not be matched with a known, trusted CA. 


° access denied: A valid certificate was received, but when access control 
was applied, the sender decided not to proceed with the negotiation. 


e decode_error: A message could not be decoded, because either a field 
was out of its specified range or the length of the message was incorrect. 


® protocol_version: The protocol version the client attempted to negoti- 
ate is recognized but not supported. 


e insufficient security: Returned instead of handshake_failure 
when a negotiation has failed specifically because the server requires ciphers 
more secure than those supported by the client. 

e unsupported_extension: Sent by clients that receive an extended server 
hello containing an extension not in the corresponding client hello. 

e internal_error: An internal error unrelated to the peer or the correct- 
ness of the protocol makes it impossible to continue. 

e decrypt_error: A handshake cryptographic operation failed, including 
being unable to verify a signature, decrypt a key exchange, or validate a fin- 
ished message. 
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The remaining alerts include the following. 


° user_canceled: This handshake is being canceled for some reason unre- 
lated to a protocol failure. 


° no_renegotiation: Sent bya client in response to a hello request or by 
the server in response to a client hello after initial handshaking. Either 
of these messages would normally result in renegotiation, but this alert 
indicates that the sender is not able to renegotiate. This message is always a 
warning. 


Cipher Suites 


There are several small differences between the cipher suites available under SSLv3 
and under TLS: 


e Key Exchange: TLS supports all of the key exchange techniques of SSLv3 
with the exception of Fortezza. 


e Symmetric Encryption Algorithms: TLS includes all of the symmetric encryp- 
tion algorithms found in SSLv3, with the exception of Fortezza. 


Client Certificate Types 


TLS defines the following certificate types to be requested in a 
certificate_request message: rsa_sign, dss_sign, rsa_fixed_dh, and 
dss_fixed_dh. These are all defined in SSLv3. In addition, SSLv3 includes 
rsa_ephemeral_dh, dss_ephemeral_dh, and fortezza_kea. Ephemeral 
Diffie-Hellman involves signing the Diffie-Hellman parameters with either RSA or 
DSS. For TLS, the rsa_sign and dss_sign types are used for that function; a 
separate signing type is not needed to sign Diffie-Hellman parameters. TLS does 
not include the Fortezza scheme. 


certificate_verify and Finished Messages 


In the TLS certificate_verify message, the MD5 and SHA-1 hashes are 
calculated only over handshake_messages. Recall that for SSLv3, the hash 
calculation also included the master secret and pads. These extra fields were felt to 
add no additional security. 

As with the finished message in SSLV3, the finished message in TLS is a hash 
based on the shared master_secret, the previous handshake messages, and a 
label that identifies client or server. The calculation is somewhat different. For TLS, 
we have 


PRF (master_secret, finished_label, MD5 (handshake_messages)| 
SHA-1 (handshake_messages) ) 


where finished_label is the string “client finished” for the client and “server 
finished” for the server. 
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Cryptographic Computations 


The pre_master_secret for TLS is calculated in the same way as in SSLv3. As in 
SSLv3, the master_secret in TLS is calculated as a hash function of the 
pre_master_secret and the two hello random numbers. The form of the TLS 
calculation is different from that of SSLv3 and is defined as 


master_secret= PRF(pre_master_secret, "master secret", 
ClientHello.random|| ServerHello.random) 


The algorithm is performed until 48 bytes of pseudorandom output are produced. 
The calculation of the key block material (MAC secret keys, session encryption 
keys, and IVs) is defined as 


key_block = PRF(master_secret, "key expansion", 
SecurityParameters.server_random|| 
SecurityParameters.client_random) 


until enough output has been generated. As with SSLv3, the key_block is a func- 
tion of the master_secret and the client and server random numbers, but for 
TLS, the actual algorithm is different. 


Padding 


In SSL, the padding added prior to encryption of user data is the minimum 
amount required so that the total size of the data to be encrypted is a multiple 
of the cipher’s block length. In TLS, the padding can be any amount that results 
in a total that is a multiple of the cipher’s block length, up to a maximum of 255 
bytes. For example, if the plaintext (or compressed text if compression is used) 
plus MAC plus padding.length byte is 79 bytes long, then the padding length 
(in bytes) can be 1,9, 17, and so on, up to 249. A variable padding length may be 
used to frustrate attacks based on an analysis of the lengths of exchanged 
messages. 


16.4 HTTPS 


HTTPS (HTTP over SSL) refers to the combination of HTTP and SSL to imple- 
ment secure communication between a Web browser and a Web server. The HTTPS 
capability is built into all modern Web browsers. Its use depends on the Web server 
supporting HTTPS communication. For example, search engines do not support 
HTTPS. 

The principal difference seen by a user of a Web browser is that URL (uni- 
form resource locator) addresses begin with https:// rather than http://. A normal 
HTTP connection uses port 80. If HTTPS is specified, port 443 is used, which 
invokes SSL. 
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When HTTPS is used, the following elements of the communication are 
encrypted: 


e URL of the requested document 

e Contents of the document 

e Contents of browser forms (filled in by browser user) 

e Cookies sent from browser to server and from server to browser 
e Contents of HTTP header 


HTTPS is documented in RFC 2818, HTTP Over TLS. There is no fundamen- 
tal change in using HTTP over either SSL or TLS, and both implementations are 
referred to as HTTPS. 


Connection Initiation 


For HTTPS, the agent acting as the HTTP client also acts as the TLS client. The 
client initiates a connection to the server on the appropriate port and then sends the 
TLS ClientHello to begin the TLS handshake. When the TLS handshake has fin- 
ished, the client may then initiate the first HTTP request. All HTTP data is to be 
sent as TLS application data. Normal HTTP behavior, including retained connec- 
tions, should be followed. 

We need to be clear that there are three levels of awareness of a connection in 
HTTPS. At the HTTP level, an HTTP client requests a connection to an HTTP 
server by sending a connection request to the next lowest layer. Typically, the next 
lowest layer is TCP, but it also may be TLS/SSL. At the level of TLS, a session is 
established between a TLS client and a TLS server. This session can support one or 
more connections at any time. As we have seen, a TLS request to establish a con- 
nection begins with the establishment of a TCP connection between the TCP entity 
on the client side and the TCP entity on the server side. 


Connection Closure 


An HTTP client or server can indicate the closing of a connection by including the 
following line in an HTTP record: Connection: close. This indicates that the 
connection will be closed after this record is delivered. 

The closure of an HTTPS connection requires that TLS close the connection 
with the peer TLS entity on the remote side, which will involve closing the underly- 
ing TCP connection. At the TLS level, the proper way to close a connection is for 
each side to use the TLS alert protocol to send a close_notify alert. TLS imple- 
mentations must initiate an exchange of closure alerts before closing a connection. 
ATLS implementation may, after sending a closure alert, close the connection with- 
out waiting for the peer to send its closure alert, generating an “incomplete close”. 
Note that an implementation that does this may choose to reuse the session. This 
should only be done when the application knows (typically through detecting HTTP 
message boundaries) that it has received all the message data that it cares about. 

HTTP clients also must be able to cope with a situation in which the underlying 
TCP connection is terminated without a prior close_notify alert and without a 
Connection: close indicator. Such a situation could be due to a programming 
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error on the server or a communication error that causes the TCP connection to drop. 
However, the unannounced TCP closure could be evidence of some sort of attack. So 
the HTTPS client should issue some sort of security warning when this occurs. 


16.5 SECURE SHELL (SSH) 


Secure Shell (SSH) is a protocol for secure network communications designed to be 
relatively simple and inexpensive to implement. The initial version, SSH1 was focused 
on providing a secure remote logon facility to replace TELNET and other remote 
logon schemes that provided no security. SSH also provides a more general 
client/server capability and can be used for such network functions as file transfer and 
e-mail. A new version, SSH2, fixes a number of security flaws in the original scheme. 
SSH2 is documented as a proposed standard in IETF RFCs 4250 through 4256. 

SSH client and server applications are widely available for most operating sys- 
tems. It has become the method of choice for remote login and X tunneling and is 
rapidly becoming one of the most pervasive applications for encryption technology 
outside of embedded systems. 

SSH is organized as three protocols that typically run on top of TCP 
(Figure 16.8): 


e Transport Layer Protocol: Provides server authentication, data confidentiality, 
and data integrity with forward secrecy (i.e., if a key is compromised during 
one session, the knowledge does not affect the security of earlier sessions). The 
transport layer may optionally provide compression. 


SSH User SSH 
Authentication Protocol Connection Protocol 
Multiplexes the encrypted 
tunnel into several logical 
channels. 


Authenticates the client-side 
user to the server. 


SSH Transport Layer Protocol 


Provides server authentication, confidentiality, and integrity. 
It may optionally also provide compression. 


TCP 


Transmission control protocol provides reliable, connection- 
oriented end-to-end delivery. 


IP 
Internet protocol provides datagram delivery across 
multiple networks. 


Figure 16.8 SSH Protocol Stack 
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e User Authentication Protocol: Authenticates the user to the server. 


e Connection Protocol: Multiplexes multiple logical communications channels 
over a single, underlying SSH connection. 


Transport Layer Protocol 


Host Keys Server authentication occurs at the transport layer, based on the server 
possessing a public/private key pair. A server may have multiple host keys using 
multiple different asymmetric encryption algorithms. Multiple hosts may share the 
same host key. In any case, the server host key is used during key exchange to 
authenticate the identity of the host. For this to be possible, the client must have a 
priori knowledge of the server’s public host key. RFC 4251 dictates two alternative 
trust models that can be used: 


1. The client has a local database that associates each host name (as typed by 
the user) with the corresponding public host key. This method requires no 
centrally administered infrastructure and no third-party coordination. The 
downside is that the database of name-to-key associations may become 
burdensome to maintain. 


Nn 


. The host name-to-key association is certified by a trusted certification author- 
ity (CA). The client only knows the CA root key and can verify the validity of 
all host keys certified by accepted CAs. This alternative eases the maintenance 
problem, since ideally, only a single CA key needs to be securely stored on the 
client. On the other hand, each host key must be appropriately certified by a 
central authority before authorization is possible. 


PackeET EXCHANGE Figure 16.9 illustrates the sequence of events in the SSH 
Transport Layer Protocol. First, the client establishes a TCP connection to the 
server. This is done via the TCP protocol and is not part of the Transport Layer 
Protocol. Once the connection is established, the client and server exchange data, 
referred to as packets, in the data field of a TCP segment. Each packet is in the 
following format (Figure 16.10). 


e Packet length: Length of the packet in bytes, not including the packet length 
and MAC fields. 


Padding length: Length of the random padding field. 


e Payload: Useful contents of the packet. Prior to algorithm negotiation, this 
field is uncompressed. If compression is negotiated, then in subsequent pack- 
ets, this field is compressed. 


e Random padding: Once an encryption algorithm has been negotiated, this 
field is added. It contains random bytes of padding so that that total length of 
the packet (excluding the MAC field) is a multiple of the cipher block size, or 
8 bytes for a stream cipher. 


e Message authentication code (MAC): If message authentication has been 
negotiated, this field contains the MAC value. The MAC value is computed 
over the entire packet plus a sequence number, excluding the MAC field. The 
sequence number is an implicit 32-bit packet sequence that is initialized to 
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Figure 16.9 SSH Transport Layer Protocol Packet Exchanges 


zero for the first packet and incremented for every packet. The sequence num- 
ber is not included in the packet sent over the TCP connection. 


Once an encryption algorithm has been negotiated, the entire packet (exclud- 
ing the MAC field) is encrypted after the MAC value is calculated. 

The SSH Transport Layer packet exchange consists of a sequence of steps 
(Figure 16.9). The first step, the identification string exchange, begins with the client 
sending a packet with an identification string of the form: 


SSH-protoversion-softwareversion SP comments CR LF 


where SP, CR, and LF are space character, carriage return, and line feed, respectively. 
An example of a valid string is SSH-2.0-billsSSH_3.6.3q3<CR><LF>. The 
server responds with its own identification string. These strings are used in the Diffie- 
Hellman key exchange. 

Next comes algorithm negotiation. Each side sends an SSH_MSG_KEXINIT con- 
taining lists of supported algorithms in the order of preference to the sender. There is 
one list for each type of cryptographic algorithm. The algorithms include key exchange, 
encryption, MAC algorithm, and compression algorithm. Table 16.3 shows the allow- 
able options for encryption, MAC, and compression. For each category, the algorithm 
chosen is the first algorithm on the client’s list that is also supported by the server. 
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Figure 16.10 
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The next step is key exchange. The specification allows for alternative methods 
of key exchange, but at present, only two versions of Diffie-Hellman key exchange are 
specified. Both versions are defined in RFC 2409 and require only one packet in each 
direction. The following steps are involved in the exchange. In this, C is the client; S is 
the server; p is a large safe prime; g is a generator for a subgroup of GF(p); q is the 
order of the subgroup; V_S is S’s identification string; V_C is C’s identification string; 


K_S is S’s public host key; I_c is C’s SSH_MSG_KEXIN 


SSH_MSG_K 


negotiation. 


EXIN 


T message and 1] 


[ Sis S’s 


T message that have been exchanged before this part begins. The 
values of p, g, and qg are known to both client and server as a result of the algorithm 
selection negotiation. The hash function hash() is also decided during algorithm 


1. C generates a random number x(1 < x < q) and computes e = g* mod p. C 
sends e to S. 


2. S generates a random number y(0 < y < q) and computes f = g” mod p. 
S receives e. It computes K = e” mod p, H = hash(V_C ll V_S II I_C|I LSI 
K Sllell fll K), and signature s on H with its private host key. S sends 
(K_S Il f lls) to C. The signing operation may involve a second hashing 
operation. 
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Table 16.3 SSH Transport Layer Cryptographic Algorithms 


Cipher MAC algorithm 


3des-cbc* 


Three-key 3DES in 
CBC mode 


hmac-sha1* 


HMAC-SHA1; digest length = 


key length = 20 


blowfish-cbec 


Blowfish in CBC mode 


hmac-sha1-96** 


First 96 bits of HMAC-SHA1; 
digest length = 12; key length = 20 


twofish256-cbc 


Twofish in CBC mode 
with a 256-bit key 


HMAC-SHAL1:; digest length = 


key length = 16 


twofish192-cbc 


Twofish with a 192-bit key 


twofish128-cbc 


Twofish with a 128-bit key 


aes256-cbc 


AES in CBC mode with a 
256-bit key 


First 96 bits of HMAC-SHA1; 
digest length = 12; key length = 16 


Compression algorithm 


aes192-cbc 


AES with a 192-bit key 


No compression 


aes128-cbc** 


AES with a 128-bit key 


Serpent256-cbc 


Serpent in CBC mode 
with a 256-bit key 


Serpent192-cbc 


Serpent with a 192-bit key 


Serpent128-cbc 


Serpent with a 128-bit key 


arcfour 


RC4 with a 128-bit key 


cast128-cbc 


CAST-128 in CBC mode 


Defined in RFC 1950 and 
RFC 1951 


* = Required 


** — Recommended 


3. C verifies that K_S really is the host key for S (e.g., using certificates or a 
local database). C is also allowed to accept the key without verification; 
however, doing so will render the protocol insecure against active attacks 
(but may be desirable for practical reasons in the short term in many 
environments). C then computes K = f* mod p, H = hash(V_Cll V_SI 
LCI LSI K_Sllell fll K), and verifies the signature s on H. 


As a result of these steps, the two sides now share a master key K. In addition, 
the server has been authenticated to the client, because the server has used its pri- 
vate key to sign its half of the Diffie-Hellman exchange. Finally, the hash value H 
serves as a session identifier for this connection. Once computed, the session identi- 
fier is not changed, even if the key exchange is performed again for this connection 
to obtain fresh keys. 

The end of key exchange is signaled by the exchange of SSH_MSG_NEWKEYS 
packets. At this point, both sides may start using the keys generated from K, as dis- 
cussed subsequently. 
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The final step is service request. The client sends an SSH_MSG_ 
SERVICE_REQUEST packet to request either the User Authentication or the 
Connection Protocol. Subsequent to this, all data is exchanged as the payload of an 
SSH Transport Layer packet, protected by encryption and MAC. 


Key GENERATION The keys used for encryption and MAC (and any needed IVs) 
are generated from the shared secret key K, the hash value from the key exchange 
H, and the session identifier, which is equal to H unless there has been a subsequent 
key exchange after the initial key exchange. The values are computed as follows. 

e Initial IV client to server: HASH(K |! H1| "A" | session_id) 

e Initial IV server to client: HASH(K || H||"B" || session_id) 

e Encryption key client to server: HASH(K || H || ""C" || session_id) 

e Encryption key server to client: HASH(K || H || "D" || session_id) 

e Integrity key client to server: HASH(K || H|| "E" || session_id) 

e Integrity key server to client: HASH(K || H|| ""F" || session_id) 


where HASH () is the hash function determined during algorithm negotiation. 


User Authentication Protocol 


The User Authentication Protocol provides the means by which the client is authen- 
ticated to the server. 


MeEssAGE TYPES AND ForMATS Three types of messages are always used in the User 
Authentication Protocol. Authentication requests from the client have the format: 


byte SSH_MSG_USERAUTH_REQUEST (50) 
string user name 

string service name 

string method name 


method specific fields 


where user name is the authorization identity the client is claiming, service name 
is the facility to which the client is requesting access (typically the SSH 
Connection Protocol), and method name is the authentication method being used 
in this request. The first byte has decimal value 50, which is interpreted as 
SSH_MSG_USERAUTH_REQUEST. 

If the server either (1) rejects the authentication request or (2) accepts the 
request but requires one or more additional authentication methods, the server 
sends a message with the format: 


byte SSH_MSG_USERAUTH_FAILURE (51) 
name-list authentications that can continue 
boolean partial success 


where the name-list is a list of methods that may productively continue the dialog. If 
the server accepts authentication, it sends a single byte message: SSH_MSG_ 
USERAUTH_SUCCESS (52). 
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MessAGE EXCHANGE The message exchange involves the following steps. 


1. 


N 


Nn 


6. 


The client sends a SSH_MSG_USERAUTH_REQUEST with a requested method 
of none. 


. The server checks to determine if the user name is valid. If not, the server returns 


SSH_MSG_USERAUTH_FAILURE with the partial success value of false. If the 
user name is valid, the server proceeds to step 3. 


. The server returns SSH_MSG_USERAUTH_FAILURE with a list of one or more 


authentication methods to be used. 


The client selects one of the acceptable authentication methods and sends a 
SSH_MSG_USERAUTH_REQUEST with that method name and the required 
method-specific fields. At this point, there may be a sequence of exchanges to 
perform the method. 


If the authentication succeeds and more authentication methods are required, the 
server proceeds to step 3, using a partial success value of true. If the authentication 
fails, the server proceeds to step 3, using a partial success value of false. 


When all required authentication methods succeed, the server sends a 
SSH_MSG_USERAUTH_SUCCESS message, and the Authentication Protocol is 
over. 


AUTHENTICATION MeTHODS The server may require one or more of the following 
authentication methods. 
° publickey: The details of this method depend on the public-key algorithm 


chosen. In essence, the client sends a message to the server that contains the 
client’s public key, with the message signed by the client’s private key. When 
the server receives this message, it checks whether the supplied key is accept- 
able for authentication and, if so, it checks whether the signature is correct. 


° password: The client sends a message containing a plaintext password, 


which is protected by encryption by the Transport Layer Protocol. 


hostbased: Authentication is performed on the client’s host rather than the 
client itself. Thus, a host that supports multiple clients would provide authenti- 
cation for all its clients. This method works by having the client send a signa- 
ture created with the private key of the client host. Thus, rather than directly 
verifying the user’s identity, the SSH server verifies the identity of the client 
host—and then believes the host when it says the user has already authenti- 
cated on the client side. 


Connection Protocol 


The SSH Connection Protocol runs on top of the SSH Transport Layer Protocol and 
assumes that a secure authentication connection is in use.? That secure authentication 


*RFC 4254, The Secure Shell (SSH) Connection Protocol, states that the Connection Protocol runs on top 
of the Transport Layer Protocol and the User Authentication Protocol. RFC 4251, SSH Protocol 
Architecture, states that the Connection Protocol runs over the User Authentication Protocol. In fact, the 
Connection Protocol runs over the Transport Layer Protocol, but assumes that the User Authentication 
Protocol has been previously invoked. 
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connection, referred to as a tunnel, is used by the Connection Protocol to multiplex a 
number of logical channels. 


CHANNEL MecHANiSM All types of communication using SSH, such as a terminal 
session, are supported using separate channels. Either side may open a channel. For 
each channel, each side associates a unique channel number, which need not be the 
same on both ends. Channels are flow controlled using a window mechanism. No 
data may be sent to a channel until a message is received to indicate that window 
space is available. 

The life of a channel progresses through three stages: opening a channel, data 
transfer, and closing a channel. 

When either side wishes to open a new channel, it allocates a local number for 
the channel and then sends a message of the form: 


byte SSH_MSG_CHANNEL_OPEN 
string channel type 

uint32 sender channel 

uint32 initial window size 

uint32 maximum packet size 


channel type specific data follows 


where uint32 means unsigned 32-bit integer. The channel type identifies the applica- 
tion for this channel, as described subsequently. The sender channel is the local 
channel number. The initial window size specifies how many bytes of channel data 
can be sent to the sender of this message without adjusting the window. The maxi- 
mum packet size specifies the maximum size of an individual data packet that can 
be sent to the sender. For example, one might want to use smaller packets for inter- 
active connections to get better interactive response on slow links. 

If the remote side is able to open the channel, it returns a SSH_MSG_ 
CHANNEL_OPEN_CONFIRMATION message, which includes the sender channel 
number, the recipient channel number, and window and packet size values for 
incoming traffic. Otherwise, the remote side returns a SSH_MSG_CHANNEL 
OPEN_FAILURE message with a reason code indicating the reason for failure. 

Once a channel is open, data transfer is performed using a SSH_MSG_ 
CHANNEL_DATA message, which includes the recipient channel number and a block 
of data. These messages, in both directions, may continue as long as the channel 
is open. 

When either side wishes to close a channel, it sends a SSH_MSG_ 
CHANNEL_CLOSE message, which includes the recipient channel number. 

Figure 16.11 provides an example of Connection Protocol Message Exchange. 


CHANNEL Types Four channel types are recognized in the SSH Connection 
Protocol specification. 


° session: The remote execution of a program. The program may be a shell, an 
application such as file transfer or e-mail, a system command, or some built-in 
subsystem. Once a session channel is opened, subsequent requests are used to 
start the remote program. 
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Figure 16.11 Example SSH Connection Protocol Message 
Exchange 


e x11: This refers to the X Window System, a computer software system and net- 
work protocol that provides a graphical user interface (GUI) for networked 
computers. X allows applications to run on a network server but to be displayed 


on a desktop machine. 


e forwarded-tcpip: This is remote port forwarding, as explained in the next sub- 


section. 


e direct-tcpip: This is local port forwarding, as explained in the next subsection. 


Port ForwarpbINnG One of the most useful features of SSH is port forwarding. In 
essence, port forwarding provides the ability to convert any insecure TCP connection 
into a secure SSH connection. This is also referred to as SSH tunneling. We need to 
know what a port is in this context. A port is an identifier of a user of TCP. So, any 
application that runs on top of TCP has a port number. Incoming TCP traffic is 
delivered to the appropriate application on the basis of the port number. An application 
may employ multiple port numbers. For example, for the Simple Mail Transfer Protocol 
(SMTP), the server side generally listens on port 25, so an incoming SMTP request uses 
TCP and addresses the data to destination port 25.TCP recognizes that this is the SMTP 


server address and routes the data to the SMTP server application. 
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Figure 16.12 illustrates the basic concept behind port forwarding. We have a 
client application that is identified by port number x and a server application identi- 
fied by port number y. At some point, the client application invokes the local TCP 
entity and requests a connection to the remote server on port y. The local TCP entity 
negotiates a TCP connection with the remote TCP entity, such that the connection 
links local port x to remote port y. 

To secure this connection, SSH is configured so that the SSH Transport Layer 
Protocol establishes a TCP connection between the SSH client and server entities 
with TCP port numbers a and J, respectively. A secure SSH tunnel is established 
over this TCP connection. Traffic from the client at port x is redirected to the local 
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Client Server 
application application 


Unsecure TCP connection 


(a) Connection via TCP 


Client Server 
application application 


Secure SSH Tunnel 


Unsecure TCP connection 


(b) Connection via SSH tunnel 


Figure 16.12 SSH Transport Layer Packet Exchanges 
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SSH entity and travels through the tunnel where the remote SSH entity delivers the 
data to the server application on port y. Traffic in the other direction is similarly 
redirected. 

SSH supports two types of port forwarding: local forwarding and remote for- 
warding. Local forwarding allows the client to set up a “hijacker” process. This will 
intercept selected application-level traffic and redirect it from an unsecured TCP 
connection to a secure SSH tunnel. SSH is configured to listen on selected ports. 
SSH grabs all traffic using a selected port and sends it through an SSH tunnel. On 
the other end, the SSH server sends the incoming traffic to the destination port dic- 
tated by the client application. 

The following example should help clarify local forwarding. Suppose you have 
an e-mail client on your desktop and use it to get e-mail from your mail server via 
the Post Office Protocol (POP). The assigned port number for POP3 is port 110. We 
can secure this traffic in the following way: 


1. The SSH client sets up a connection to the remote server. 


2. Select an unused local port number, say 9999, and configure SSH to accept 
traffic from this port destined for port 110 on the server. 


3. The SSH client informs the SSH server to create a connection to the destina- 
tion, in this case mailserver port 110. 


4. The client takes any bits sent to local port 9999 and sends them to the server 
inside the encrypted SSH session. The SSH server decrypts the incoming bits 
and sends the plaintext to port 110. 


5. In the other direction, the SSH server takes any bits received on port 110 
and sends them inside the SSH session back to the client, who decrypts and 
sends them to the process connected to port 9999. 


With remote forwarding, the user’s SSH client acts on the server’s behalf. 
The client receives traffic with a given destination port number, places the traffic 
on the correct port and sends it to the destination the user chooses. A typical 
example of remote forwarding is the following. You wish to access a server at 
work from your home computer. Because the work server is behind a firewall, it 
will not accept an SSH request from your home computer. However, from work 
you can set up an SSH tunnel using remote forwarding. This involves the follow- 
ing steps. 


1. From the work computer, set up an SSH connection to your home 
computer. The firewall will allow this, because it is a protected outgoing 
connection. 
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. Configure the SSH server to listen on a local port, say 22, and to deliver data 
across the SSH connection addressed to remote port, say 2222. 


3. You can now go to your home computer, and configure SSH to accept traffic 
on port 2222. 


4. You now have an SSH tunnel that can be used for remote logon to the work 
server. 
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16.6 RECOMMENDED READING AND WEB SITES 


[RESCO01] is a good detailed treatment of SSL and TLS. [BARROS] provides a thorough 
treatment of SSH. The original version (SSH-1) of SSH was introduced in [YLON96]. 


BARROS Barrett, D.; Silverman, R.; and Byrnes, R. SSH The Secure Shell: The Definitive 
Guide. Sebastopol, CA: O’ Reilly, 2005. 

RESCO1_ Rescorla, E. SSL and TLS: Designing and Building Secure Systems. Reading, 
MA: Addison-Wesley, 2001. 


YLON96_ Ylonen, T. “SSH - Secure Login Connections over the Internet.” Proceedings, 
Sixth USENIX Security Symposium, July 1996. 


Recommended Web Sites: 
e Transport Layer Security Charter: Latest RFCs and Internet drafts for TLS. 


e¢ OpenSSL Project: Project to develop open-source SSL and TLS software. Site includes 
documents and links. 
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Key Terms 


Alert protocol HTTPS (HTTP over SSL) Secure Socket Layer (SSL) 


Change Cipher Spec protocol | Master Secret Transport Layer Security 
Handshake protocol Secure Shell (SSH) (TLS) 


Review Questions 


16.1 What are the advantages of each of the three approaches shown in Figure 16.1? 
16.2 What protocols comprise SSL? 
16.3 What is the difference between an SSL connection and an SSL session? 
16.4 List and briefly define the parameters that define an SSL session state. 
16.5 List and briefly define the parameters that define an SSL session connection. 
16.6 What services are provided by the SSL Record Protocol? 
16.7 What steps are involved in the SSL Record Protocol transmission? 
16.8 What is the purpose of HTTPS? 
16.9 For what applications is SSH useful? 
16.10 List and briefly define the SSH protocols. 
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Problems 


16.1 


16.2 
16.3 


16.4 


16.5 


In SSL and TLS, why is there a separate Change Cipher Spec Protocol rather than 
including a change_cipher_spec message in the Handshake Protocol? 


What purpose does the MAC serve during the change cipher spec SSL exchange? 


Consider the following threats to Web security and describe how each is countered by 
a particular feature of SSL. 


a. 


b. 


Brute-Force Cryptanalytic Attack: An exhaustive search of the key space for a 
conventional encryption algorithm. 

Known Plaintext Dictionary Attack: Many messages will contain predictable 
plaintext, such as the HTTP GET command. An attacker constructs a dictionary 
containing every possible encryption of the known-plaintext message. When an 
encrypted message is intercepted, the attacker takes the portion containing the 
encrypted known plaintext and looks up the ciphertext in the dictionary. The 
ciphertext should match against an entry that was encrypted with the same secret 
key. If there are several matches, each of these can be tried against the full cipher- 
text to determine the right one. This attack is especially effective against small key 
sizes (e.g., 40-bit keys). 

Replay Attack: Earlier SSL handshake messages are replayed. 
Man-in-the-Middle Attack: An attacker interposes during key exchange, acting as 
the client to the server and as the server to the client. 

Password Sniffing: Passwords in HTTP or other application traffic are eaves- 
dropped. 

IP Spoofing: Uses forged IP addresses to fool a host into accepting bogus data. 
IP Hijacking: An active, authenticated connection between two hosts is disrupted 
and the attacker takes the place of one of the hosts. 


. SYN Flooding: An attacker sends TCP SYN messages to request a connection but 


does not respond to the final message to establish the connection fully. The 
attacked TCP module typically leaves the “half-open connection” around for a 
few minutes. Repeated SYN messages can clog the TCP module. 


Based on what you have learned in this chapter, is it possible in SSL for the receiver 
to reorder SSL record blocks that arrive out of order? If so, explain how it can be 
done. If not, why not? 

For SSH packets, what is the advantage, if any, of not including the MAC in the scope 
of the packet encryption? 
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Investigators have published numerous reports of birds taking turns vocalizing; 
the bird spoken to gave its full attention to the speaker and never vocalized at the 
same time, as if the two were holding a conversation. 


Researchers and scholars who have studied the data on avian communication 
carefully write (a) the communication code of birds, such as crows, has not been 
broken by any means; (b) probably all birds have wider vocabularies than any- 
one realizes; and (c) greater complexity and depth are recognized in avian com- 
munication as research progresses. 


—The Human Nature of Birds, Theodore Barber 


KEY POINTS 


® IEEE 802.11 is a standard for wireless LANs. Interoperable standards- 
compliant implementations are referred to as Wi-Fi. 


® IEEE 802.111 specifies security standards for IEEE 802.11 LANs, includ- 
ing authentication, data integrity, data confidentiality, and key manage- 
ment. Interoperable implementations are also referred to as Wi-Fi 
Protected Access (WPA). 


® The Wireless Application Protocol (WAP) is a standard to provide mobile 
users of wireless phones and other wireless terminals access to telephony 
and information services, including the Internet and the Web. 


® WAP security is primarily provided by the Wireless Transport Layer Secu- 
rity (WTLS), which provides security services between the mobile device 
and the WAP gateway to the Internet. 

© There are several approaches to WAP end-to-end security. One notable 
approach assumes that the mobile device implements TLS over TCP/IP 
and the wireless network supports transfer of IP packets. 


This chapter looks at two important wireless network security schemes. First, we look 
at the IEEE 802.111 standard for wireless LAN security. This standard is part of IEEE 
802.11, also referred to as Wi-Fi. We begin the discussion with an overview of IEEE 
802.11, and we then look in some detail at IEEE 802.111. 

The remainder of the chapter is devoted to security standards for Web access 
from mobile wireless devices, such as cell phones. We begin this part of the chapter with 
an overview of the Wireless Application Protocol (WAP), which is a set of standards 
for communication between mobile devices attached to a cellular network and a Web 
server. Then we examine the Wireless Transport Layer Security (WTLS) protocol, 
which provides security between the mobile device and a gateway that operates 
between the cellular network and the Internet. Finally, we cover end-to-end security 
services between WAP devices and Web servers. 
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17.1 TEEE 802.11 WIRELESS LAN OVERVIEW 


IEEE 802 is a committee that has developed standards for a wide range of local area 
networks (LANs). In 1990, the IEEE 802 Committee formed a new working group, 
IEEE 802.11, with a charter to develop a protocol and transmission specifications 
for wireless LANs (WLANs). Since that time, the demand for WLANs at different 
frequencies and data rates has exploded. Keeping pace with this demand, the IEEE 
802.11 working group has issued an ever-expanding list of standards. Table 17.1 
briefly defines key terms used in the IEEE 802.11 standard. 


The Wi-Fi Alliance 


The first 802.11 standard to gain broad industry acceptance was 802.11b. Although 
802.11b products are all based on the same standard, there is always a concern 
whether products from different vendors will successfully interoperate. To meet this 
concern, the Wireless Ethernet Compatibility Alliance (WECA), an industry con- 
sortium, was formed in 1999. This organization, subsequently renamed the Wi-Fi 
(Wireless Fidelity) Alliance, created a test suite to certify interoperability for 
802.11b products. The term used for certified 802.11b products is Wi-Fi. Wi-Fi certi- 
fication has been extended to 802.11g products,. The Wi-Fi Alliance has also devel- 
oped a certification process for 802.11a products, called Wi-Fi5. The Wi-Fi Alliance 
is concerned with a range of market areas for WLANs, including enterprise, home, 
and hot spots. 

Mote recently, the Wi-Fi Alliance has developed certification procedures for 
IEEE 802.11 security standards, referred to as Wi-Fi Protected Access (WPA). The 
most recent version of WPA, known as WPA2, incorporates all of the features of the 
IEEE 802.111 WLAN security specification. 


Table 17.1. TEEE 802.11 Terminology 


Access point (AP) Any entity that has station functionality and provides access to the distribution 


system via the wireless medium for associated stations. 


Basic service set (BSS) A set of stations controlled by a single coordination function. 


Coordination function The logical function that determines when a station operating within a BSS is per- 


mitted to transmit and may be able to receive PDUs. 


Distribution system 


(DS) 


Extended service set 


(ESS) 


MAC protocol data unit 
(MPDU) 


MAC service data unit 
(MSDU) 


Station 


A system used to interconnect a set of BSSs and integrated LANs to create an 
ESS. 


A set of one or more interconnected BSSs and integrated LANs that appear as a 
single BSS to the LLC layer at any station associated with one of these BSSs. 


The unit of data exchanged between two peer MAC entities using the services of 
the physical layer. 


Information that is delivered as a unit between MAC users. 


Any device that contains an IEEE 802.11 conformant MAC and physical layer. 
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IEEE 802 Protocol Architecture 


Before proceeding, we need to briefly preview the IEEE 802 protocol architecture. 
IEEE 802.11 standards are defined within the structure of a layered set of protocols. 
This structure, used for all IEEE 802 standards, is illustrated in Figure 17.1. 


PuysicAL LAyER The lowest layer of the IEEE 802 reference model is the physical 
layer, which includes such functions as encoding/decoding of signals and bit 
transmission/reception. In addition, the physical layer includes a specification of the 
transmission medium. In the case of IEEE 802.11, the physical layer also defines 
frequency bands and antenna characteristics. 


MepiA Access ConTROL All LANs consist of collections of devices that share the 
network’s transmission capacity. Some means of controlling access to the 
transmission medium is needed to provide an orderly and efficient use of that 
capacity. This is the function of a media access control (MAC) layer. The MAC layer 
receives data from a higher-layer protocol, typically the Logical Link Control (LLC) 
layer, in the form of a block of data known as the MAC service data unit (MSDU). 
In general, the MAC layer performs the following functions: 


e On transmission, assemble data into a frame, known as a MAC protocol data 
unit (MPDU) with address and error-detection fields. 


e On reception, disassemble frame, and perform address recognition and error 
detection. 


e Govern access to the LAN transmission medium. 


General IEEE 802 Specific IEEE 802.11 
functions functions 


mer 


Logical Link Flow control 
Control Error control 


Assemble data into frame 

Medium Access Addressing Reliable data delivery 

Error detection Wireless access control protocols 
Medium access 


Control 


Encoding/decoding of signals 
i Bit transmission/reception 
Physical Transmission medium 


Frequency band definition 
Wireless signal encoding 


Figure 17.1 TEEE 802.11 Protocol Stack 
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MAC Destination Source : : 
Control | MAC Address | MAC Address | MAC Service Data Unit (MSDU) CRC 


MAC header MAC trailer 
Figure 17.2 General IEEE 802 MPDU Format 


The exact format of the MPDU differs somewhat for the various MAC proto- 
cols in use. In general, all of the MPDUs have a format similar to that of Figure 17.2. 
The fields of this frame are as follows. 


e MAC Control: This field contains any protocol control information needed for 
the functioning of the MAC protocol. For example, a priority level could be 
indicated here. 


¢ Destination MAC Address: The destination physical address on the LAN for 
this MPDU. 


Source MAC Address: The source physical address on the LAN for this 
MPDU. 


e MAC Service Data Unit: The data from the next higher layer. 


e CRC: The cyclic redundancy check field; also known as the Frame Check 
Sequence (FCS) field. This is an error-detecting code, such as that which is 
used in other data-link control protocols. The CRC is calculated based on the 
bits in the entire MPDU. The sender calculates the CRC and adds it to the 
frame. The receiver performs the same calculation on the incoming MPDU 
and compares that calculation to the CRC field in that incoming MPDU. If the 
two values don’t match, then one or more bits have been altered in transit. 


The fields preceding the MSDU field are referred to as the MAC header, and 
the field following the MSDU field is referred to as the MAC trailer. The header and 
trailer contain control information that accompany the data field and that are used 
by the MAC protocol. 


LocicaL LINK ConTrot In most data-link control protocols, the data-link protocol 
entity is responsible not only for detecting errors using the CRC, but for recovering 
from those errors by retransmitting damaged frames. In the LAN protocol 
architecture, these two functions are split between the MAC and LLC layers. The 
MAC layer is responsible for detecting errors and discarding any frames that 
contain errors. The LLC layer optionally keeps track of which frames have been 
successfully received and retransmits unsuccessful frames. 


IEEE 802.11 Network Components and Architectural Model 


Figure 17.3 illustrates the model developed by the 802.11 working group. The smallest 
building block of a wireless LAN is a basic service set (BSS), which consists of wireless 
stations executing the same MAC protocol and competing for access to the same 
shared wireless medium. A BSS may be isolated, or it may connect to a backbone 
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Figure 17.3 IEEE 802.11 Extended Service Set 


distribution system (DS) through an access point (AP). The AP functions as a bridge 
and a relay point. In a BSS, client stations do not communicate directly with one 
another. Rather, if one station in the BSS wants to communicate with another station 
in the same BSS, the MAC frame is first sent from the originating station to the AP 
and then from the AP to the destination station. Similarly, a MAC frame from a sta- 
tion in the BSS to a remote station is sent from the local station to the AP and then 
relayed by the AP over the DS on its way to the destination station. The BSS generally 
corresponds to what is referred to as a cell in the literature. The DS can be a switch, a 
wired network, or a wireless network. 

When all the stations in the BSS are mobile stations that communicate directly 
with one another (not using an AP), the BSS is called an independent BSS (IBSS). 
An IBSS is typically an ad hoc network. In an IBSS, the stations all communicate 
directly, and no AP is involved. 

A simple configuration is shown in Figure 17.3, in which each station belongs 
to a single BSS; that is, each station is within wireless range only of other stations 
within the same BSS. It is also possible for two BSSs to overlap geographically, so 
that a single station could participate in more than one BSS. Furthermore, the asso- 
ciation between a station and a BSS is dynamic. Stations may turn off, come within 
range, and go out of range. 

An extended service set (ESS) consists of two or more basic service sets 
interconnected by a distribution system. The extended service set appears as a single 
logical LAN to the logical link control (LLC) level. 


17.1 / IEEE 802.11 WIRELESS LAN OVERVIEW 527 


IEEE 802.11 Services 


IEEE 802.11 defines nine services that need to be provided by the wireless LAN to 
achieve functionality equivalent to that which is inherent to wired LANs. Table 17.2 
lists the services and indicates two ways of categorizing them. 


1. The service provider can be either the station or the DS. Station services are 
implemented in every 802.11 station, including AP stations. Distribution ser- 
vices are provided between BSSs; these services may be implemented in an AP 
or in another special-purpose device attached to the distribution system. 

. Three of the services are used to control IEEE 802.11 LAN access and confi- 
dentiality. Six of the services are used to support delivery of MSDUs between 
stations. If the MSDU is too large to be transmitted in a single MPDU, it may 
be fragmented and transmitted in a series of MPDUs. 
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Following the IEEE 802.11 document, we next discuss the services in an order 
designed to clarify the operation of an IEEE 802.11 ESS network. MSDU delivery, 
which is the basic service, already has been mentioned. Services related to security 
are introduced in Section 17.2. 


DISTRIBUTION OF MESSAGES WITHIN A DS The two services involved with the 
distribution of messages within a DS are distribution and integration. Distribution is 
the primary service used by stations to exchange MPDUs when the MPDUs must 
traverse the DS to get from a station in one BSS to a station in another BSS. For 
example, suppose a frame is to be sent from station 2 (STA 2) to station 7 (STA 7) in 
Figure 17.3. The frame is sent from STA 2 to AP 1, which is the AP for this BSS. The 
AP gives the frame to the DS, which has the job of directing the frame to the AP 
associated with STA 7 in the target BSS. AP 2 receives the frame and forwards it to 
STA 7. How the message is transported through the DS is beyond the scope of the 
IEEE 802.11 standard. 

If the two stations that are communicating are within the same BSS, then the 
distribution service logically goes through the single AP of that BSS. 


Table 17.2, IEEE 802.11 Services 


Service Provider Used to support 
Association Distribution system MSDU delivery 
Authentication Station LAN access and security 
Deauthentication Station LAN access and security 
Disassociation Distribution system MSDU delivery 
Distribution Distribution system MSDU delivery 
Integration Distribution system MSDU delivery 
MSDU delivery Station MSDU delivery 
Privacy Station LAN access and security 
Reassociation Distribution system MSDU delivery 
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The integration service enables transfer of data between a station on an IEEE 
802.11 LAN and a station on an integrated IEEE 802.x LAN. The term integrated 
refers to a wired LAN that is physically connected to the DS and whose stations 
may be logically connected to an IEEE 802.11 LAN via the integration service. The 
integration service takes care of any address translation and media conversion logic 
required for the exchange of data. 


ASSOCIATION-RELATED Services The primary purpose of the MAC layer is to 
transfer MSDUs between MAC entities; this purpose is fulfilled by the 
distribution service. For that service to function, it requires information about 
stations within the ESS that is provided by the association-related services. Before 
the distribution service can deliver data to or accept data from a station, that 
station must be associated. Before looking at the concept of association, we need 
to describe the concept of mobility. The standard defines three transition types, 
based on mobility: 


e No transition: A station of this type is either stationary or moves only within 
the direct communication range of the communicating stations of a single BSS. 


e BSS transition: This is defined as a station movement from one BSS to 
another BSS within the same ESS. In this case, delivery of data to the station 
requires that the addressing capability be able to recognize the new location 
of the station. 


e ESS transition: This is defined as a station movement from a BSS in one ESS 
to a BSS within another ESS. This case is supported only in the sense that the 
station can move. Maintenance of upper-layer connections supported by 
802.11 cannot be guaranteed. In fact, disruption of service is likely to occur. 


To deliver a message within a DS, the distribution service needs to know 
where the destination station is located. Specifically, the DS needs to know the 
identity of the AP to which the message should be delivered in order for that mes- 
sage to reach the destination station. To meet this requirement, a station must 
maintain an association with the AP within its current BSS. Three services relate to 
this requirement: 


e Association: Establishes an initial association between a station and an AP. 
Before a station can transmit or receive frames on a wireless LAN, its identity 
and address must be known. For this purpose, a station must establish an asso- 
ciation with an AP within a particular BSS. The AP can then communicate this 
information to other APs within the ESS to facilitate routing and delivery of 
addressed frames. 


e Reassociation: Enables an established association to be transferred from one 
AP to another, allowing a mobile station to move from one BSS to another. 


e Disassociation: A notification from either a station or an AP that an existing 
association is terminated. A station should give this notification before leaving 
an ESS or shutting down. However, the MAC management facility protects 
itself against stations that disappear without notification. 
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17.2 TEEE 802.11i WIRELESS LAN SECURITY 


There are two characteristics of a wired LAN that are not inherent in a wireless LAN. 


1. In order to transmit over a wired LAN, a station must be physically connected 
to the LAN. On the other hand, with a wireless LAN, any station within radio 
range of the other devices on the LAN can transmit. In a sense, there is a form 
of authentication with a wired LAN in that it requires some positive and 
presumably observable action to connect a station to a wired LAN. 
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Similarly, in order to receive a transmission from a station that is part of a 
wired LAN, the receiving station also must be attached to the wired LAN. On 
the other hand, with a wireless LAN, any station within radio range can 
receive. Thus, a wired LAN provides a degree of privacy, limiting reception of 
data to stations connected to the LAN. 


These differences between wired and wireless LANs suggest the increased 
need for robust security services and mechanisms for wireless LANs. The original 
802.11 specification included a set of security features for privacy and authentication 
that were quite weak. For privacy, 802.11 defined the Wired Equivalent Privacy 
(WEP) algorithm. The privacy portion of the 802.11 standard contained major weak- 
nesses. Subsequent to the development of WEP, the 802.111 task group has developed 
a set of capabilities to address the WLAN security issues. In order to accelerate the 
introduction of strong security into WLANs, the Wi-Fi Alliance promulgated Wi-Fi 
Protected Access (WPA) as a Wi-Fi standard. WPA is a set of security mechanisms 
that eliminates most 802.11 security issues and was based on the current state of the 
802.111 standard. The final form of the 802.111 standard is referred to as Robust 
Security Network (RSN). The Wi-Fi Alliance certifies vendors in compliance with the 
full 802.111 specification under the WPA2 program. 


IEEE 802.11i Services 
The 802.111 RSN security specification defines the following services. 


e Authentication: A protocol is used to define an exchange between a user and 
an AS that provides mutual authentication and generates temporary keys to 
be used between the client and the AP over the wireless link. 


e Access control:! This function enforces the use of the authentication function, 
routes the messages properly, and facilitates key exchange. It can work with a 
variety of authentication protocols. 


e Privacy with message integrity: MAC-level data (e.g., an LLC PDU) are 
encrypted along with a message integrity code that ensures that the data have 
not been altered. 


Figure 17.4a indicates the security protocols used to support these services, 
while Figure 17.4b lists the cryptographic algorithms used for these services. 


'Tn this context, we are discussing access control as a security function. This is a different function than 
media access control (MAC) as described in Section 17.1. Unfortunately, the literature and the standards 
use the term access control in both contexts. 
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(b) Cryptographic algorithms 


CBC-MAC = Cipher Block Block Chaining Message Authentication Code (MAC) 
CCM = Counter Mode with Cipher Block Chaining Message Authentication Code 
CCMP = Counter Mode with Cipher Block Chaining MAC Protocol 

TKIP = Temporal Key Integrity Protocol 


Figure 17.4 Elements of IEEE 802.111 


IEEE 802.11i Phases of Operation 


The operation of an IEEE 802.111 RSN can be broken down into five distinct phases 
of operation. The exact nature of the phases will depend on the configuration and 
the end points of the communication. Possibilities include (see Figure 17.3): 


1. Two wireless stations in the same BSS communicating via the access point 
(AP) for that BSS. 

2. Two wireless stations (STAs) in the same ad hoc IBSS communicating directly 
with each other. 

3. Two wireless stations in different BSSs communicating via their respective APs 
across a distribution system. 


4. A wireless station communicating with an end station on a wired network via 
its AP and the distribution system. 


17.2 / IEEE 802.111 WIRELESS LAN SECURITY 531 


IEEE 802.111 security is concerned only with secure communication between 
the STA and its AP. In case 1 in the preceding list, secure communication is assured 
if each STA establishes secure communications with the AP. Case 2 is similar, with 
the AP functionality residing in the STA. For case 3, security is not provided across 
the distribution system at the level of IEEE 802.11, but only within each BSS. End- 
to-end security (if required) must be provided at a higher layer. Similarly, in case 4, 
security is only provided between the STA and its AP. 

With these considerations in mind, Figure 17.5 depicts the five phases of oper- 
ation for an RSN and maps them to the network components involved. One new 
component is the authentication server (AS). The rectangles indicate the exchange 
of sequences of MPDUs. The five phases are defined as follows. 


e Discovery: An AP uses messages called Beacons and Probe Responses to 
advertise its IEEE 802.111 security policy. The STA uses these to identify an 
AP for a WLAN with which it wishes to communicate. The STA associates 
with the AP, which it uses to select the cipher suite and authentication mecha- 
nism when the Beacons and Probe Responses present a choice. 


e Authentication: During this phase, the STA and AS prove their identities to 
each other. The AP blocks non-authentication traffic between the STA and AS 
until the authentication transaction is successful. The AP does not participate 
in the authentication transaction other than forwarding traffic between the 
STA and AS. 


STA AP AS End Station 


Phase 5 - Connection Termination 


Figure 17.5 TEEE 802.111 Phases of Operation 
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e Key generation and distribution: The AP and the STA perform several opera- 
tions that cause cryptographic keys to be generated and placed on the AP and 
the STA. Frames are exchanged between the AP and STA only. 


Protected data transfer: Frames are exchanged between the STA and the end 
station through the AP. As denoted by the shading and the encryption module 
icon, secure data transfer occurs between the STA and the AP only; security is 
not provided end-to-end. 


e Connection termination: The AP and STA exchange frames. During this 
phase, the secure connection is torn down and the connection is restored to the 
original state. 


Discovery Phase 


We now look in more detail at the RSN phases of operation, beginning with the 
discovery phase, which is illustrated in the upper portion of Figure 17.6. The purpose 
of this phase is for an STA and an AP to recognize each other, agree on a set of secu- 
rity capabilities, and establish an association for future communication using those 
security capabilities. 
SecuRITY CApaBiLiTiEs During this phase, the STA and AP decide on specific 
techniques in the following areas: 
e Confidentiality and MPDU integrity protocols for protecting unicast traffic 
(traffic only between this STA and AP) 
e Authentication method 
e Cryptography key management approach 
Confidentiality and integrity protocols for protecting multicast/broadcast traf- 
fic are dictated by the AP, since all STAs in a multicast group must use the same pro- 
tocols and ciphers. The specification of a protocol, along with the chosen key length 


(if variable) is known as a cipher suite. The options for the confidentiality and 
integrity cipher suite are 


e WEP, with either a 40-bit or 104-bit key, which allows backward compatibility 
with older IEEE 802.11 implementations 
e TKIP 
e CCMP 
e Vendor-specific methods 
The other negotiable suite is the authentication and key management (AKM) 
suite, which defines (1) the means by which the AP and STA perform mutual 


authentication and (2) the means for deriving a root key from which other keys may 
be generated. The possible AKM suites are 


e TERE 802.1X 


e Pre-shared key (no explicit authentication takes place and mutual authentica- 
tion is implied if the STA and AP share a unique secret key) 


e Vendor-specific methods 
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Figure 17.6 TEEE 802.111 Phases of Operation: Capability Discovery, 
Authentication, and Association 


MPDU ExcuaAnceE The discovery phase consists of three exchanges. 


333 


e Network and security capability discovery: During this exchange, STAs dis- 
cover the existence of a network with which to communicate. The AP either 
periodically broadcasts its security capabilities (not shown in figure), indicated 
by RSN IE (Robust Security Network Information Element), in a specific 
channel through the Beacon frame; or responds to a station’s Probe Request 
through a Probe Response frame. A wireless station may discover available 
access points and corresponding security capabilities by either passively mon- 


itoring the Beacon frames or actively probing every channel. 


e Open system authentication: The purpose of this frame sequence, which pro- 
vides no security, is simply to maintain backward compatibility with the 
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IEEE 802.11 state machine, as implemented in existing IEEE 802.11 hard- 
ware. In essence, the two devices (STA and AP) simply exchange identifiers. 


e Association: The purpose of this stage is to agree on a set of security capabili- 
ties to be used. The STA then sends an Association Request frame to the AP. 
In this frame, the STA specifies one set of matching capabilities (one authenti- 
cation and key management suite, one pairwise cipher suite, and one group- 
key cipher suite) from among those advertised by the AP. If there is no match 
in capabilities between the AP and the STA, the AP refuses the Association 
Request. The STA blocks it too, in case it has associated with a rogue AP or 
someone is inserting frames illicitly on its channel. As shown in Figure 17.6, the 
IEEE 802.1X controlled ports are blocked, and no user traffic goes beyond the 
AP. The concept of blocked ports is explained subsequently. 


Authentication Phase 


As was mentioned, the authentication phase enables mutual authentication between 
an STA and an authentication server (AS) located in the DS. Authentication is 
designed to allow only authorized stations to use the network and to provide the 
STA with assurance that it is communicating with a legitimate network. 


IEEE 802.1X Access CONTROL ApproAacH IEEE 802.11i makes use of another 
standard that was designed to provide access control functions for LANs. The 
standard is IEEE 802.1X, Port-Based Network Access Control. The authentication 
protocol that is used, the Extensible Authentication Protocol (EAP), is defined in 
the IEEE 802.1X standard. IEEE 802.1X uses the terms supplicant, authenticator, 
and authentication server (AS). In the context of an 802.11 WLAN, the first two 
terms correspond to the wireless station and the AP. The AS is typically a separate 
device on the wired side of the network (i.e., accessible over the DS) but could also 
reside directly on the authenticator. 

Before a supplicant is authenticated by the AS using an authentication proto- 
col, the authenticator only passes control or authentication messages between the 
supplicant and the AS; the 802.1X control channel is unblocked, but the 802.11 data 
channel is blocked. Once a supplicant is authenticated and keys are provided, the 
authenticator can forward data from the supplicant, subject to predefined access 
control limitations for the supplicant to the network. Under these circumstances, the 
data channel is unblocked. 

As indicated in Figure 17.7, 802.1X uses the concepts of controlled and uncon- 
trolled ports. Ports are logical entities defined within the authenticator and refer to 
physical network connections. For a WLAN, the authenticator (the AP) may have 
only two physical ports: one connecting to the DS and one for wireless communica- 
tion within its BSS. Each logical port is mapped to one of these two physical ports. 
An uncontrolled port allows the exchange of PDUs between the supplicant and the 
other AS, regardless of the authentication state of the supplicant. A controlled port 
allows the exchange of PDUs between a supplicant and other systems on the LAN 
only if the current state of the supplicant authorizes such an exchange. 

The 802.1X framework, with an upper-layer authentication protocol, fits nicely 
with a BSS architecture that includes a number of wireless stations and an AP. 
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However, for an IBSS, there is no AP. For an IBSS, 802.111 provides a more complex 
solution that, in essence, involves pairwise authentication between stations on the 
IBSS. 


MPDU ExcuaAnce The lower part of Figure 17.6 shows the MPDU exchange 
dictated by IEEE 802.11 for the authentication phase. We can think of 
authentication phase as consisting of the following three phases. 


e Connect to AS: The STA sends a request to its AP (the one with which it has 
an association) for connection to the AS. The AP acknowledges this request 
and sends an access request to the AS. 

e EAP exchange: This exchange authenticates the STA and AS to each other. 
A number of alternative exchanges are possible, as explained subsequently. 


Secure key delivery: Once authentication is established, the AS generates a 
master session key (MSK), also known as the Authentication, 
Authorization, and Accounting (AAA) key and sends it to the STA. 
As explained subsequently, all the cryptographic keys needed by the STA 
for secure communication with its AP are generated from this MSK. IEEE 
802.111 does not prescribe a method for secure delivery of the MSK but 
relies on EAP for this. Whatever method is used, it involves the transmis- 
sion of an MPDU containing an encrypted MSK from the AS, via the AP, to 
the AS. 


EAP ExcHaAnceE As mentioned, there are a number of possible EAP exchanges 
that can be used during the authentication phase. Typically, the message flow 
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between STA and AP employs the EAP over LAN (EAPOL) protocol, and the 
message flow between the AP and AS uses the Remote Authentication Dial In User 
Service (RADIUS) protocol, although other options are available for both STA-to- 
AP and AP-to-AS exchanges. [FRAN0O7] provides the following summary of the 
authentication exchange using EAPOL and RADIUS. 


1. The EAP exchange begins with the AP issuing an EAP-Request/Identity 
frame to the STA. 


. The STA replies with an EAP-Response/Identity frame, which the 
AP receives over the uncontrolled port. The packet is then encapsulated 
in RADIUS over EAP and passed on to the RADIUS server as a 
RADIUS-Access-Request packet. 


3. The AAA server replies with a RADIUS-Access-Challenge packet, which is 
passed on to the STA as an EAP-Request. This request is of the appropriate 
authentication type and contains relevant challenge information. 


4. The STA formulates an EAP-Response message and sends it to the AS. The 
response is translated by the AP into a Radius-Access-Request with the 
response to the challenge as a data field. Steps 3 and 4 may be repeated multi- 
ple times, depending on the EAP method in use. For TLS tunneling methods, 
it is common for authentication to require 10 to 20 round trips. 


i) 


1) 


. The AAA server grants access with a Radius-Access-Accept packet. The 
AP issues an EAP-Success frame. (Some protocols require confirmation of 
the EAP success inside the TLS tunnel for authenticity validation.) The 
controlled port is authorized, and the user may begin to access the network. 


Note from Figure 17.6 that the AP controlled port is still blocked to general 
user traffic. Although the authentication is successful, the ports remain blocked until 
the temporal keys are installed in the STA and AP, which occurs during the 4-Way 
Handshake. 


Key Management Phase 


During the key management phase, a variety of cryptographic keys are generated 
and distributed to STAs. There are two types of keys: pairwise keys used for commu- 
nication between an STA and an AP and group keys used for multicast communica- 
tion. Figure 17.8, based on [FRANO7], shows the two key hierarchies, and Table 17.3 
defines the individual keys. 


ParrwisE Keys Pairwise keys are used for communication between a pair of 
devices, typically between an STA and an AP. These keys form a hierarchy 
beginning with a master key from which other keys are derived dynamically and 
used for a limited period of time. 

At the top level of the hierarchy are two possibilities. A pre-shared key (PSK) 
is a secret key shared by the AP and a STA and installed in some fashion outside 
the scope of IEEE 802.111. The other alternative is the master session key (MSK), 
also known as the AAAK, which is generated using the IEEE 802.1X protocol dur- 
ing the authentication phase, as described previously. The actual method of key 
generation depends on the details of the authentication protocol used. In either 
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Figure 17.8 TEEE 802.111 Key Hierarchies 


case (PSK or MSK), there is a unique key shared by the AP with each STA with 
which it communicates. All the other keys derived from this master key are also 
unique between an AP and an STA. Thus, each STA, at any time, has one set of 
keys, as depicted in the hierarchy of Figure 17.8a, while the AP has one set of such 
keys for each of its STAs. 

The pairwise master key (PMK) is derived from the master key. If a PSK is 
used, then the PSK is used as the PMK; if a MSK is used, then the PMK is derived 
from the MSK by truncation (if necessary). By the end of the authentication phase, 
marked by the 802.1x EAP Success message (Figure 17.6), both the AP and the STA 
have a copy of their shared PMK. 


Table 17.3 


MRK SECURITY 


IEEE 802.111 Keys for Data Confidentiality and Integrity Protocols 


Abbrey- Name Description / Purpose Size (bits) Type 
iation 
AAA Authentication, Used to derive the PMK. Used with = 256 Key generation 
Key Accounting, and the IEEE 802.1X authentication and key, root key 
Authorization Key key management approach. Same as 
MMSK. 
PSK Pre-shared Key Becomes the PMK in pre-shared 256 Key generation 
key environments. key, root key 
PMK Pairwise Master Key | Used with other inputs to derive the 256 Key generation 
PTK. key 
GMK Group Master Key Used with other inputs to derive the 128 Key generation 
GTK. key 
PTK Pair-wise Transient Derived from the PMK. Comprises 512 (TKIP) Composite key 
Key the EAPOL-KCK, EAPOL-KEK, 384 (CCMP) 
and TK and (for TKIP) the MIC 
key. 
TK Temporal Key Used with TKIP or CCMP to pro- 256 (TKIP) Traffic key 
vide confidentiality and integrity 128 (CCMP) 
protection for unicast user traffic. 
GTK Group Temporal Derived from the GMK. Used to 256 (TKIP) Traffic key 
Key provide confidentiality and integrity 128 (CCMP) 
protection for multicast/broadcast 40, 104 (WEP) 
user traffic. 
MIC Message Integrity Used by TKIP’s Michael MIC to 64 Message 
Key Code Key provide integrity protection of integrity key 
messages. 
EAPOL- | EAPOL-Key Used to provide integrity protection 128 Message 
KCK Confirmation Key for key material distributed during integrity key 
the 4-Way Handshake. 
EAPOL- | EAPOL-Key Used to ensure the confidentiality of 128 Traffic key / 
KEK Encryption Key the GTK and other key material in key encryption 
the 4-Way Handshake. key 
WEP Wired Equivalent Used with WEP. 40, 104 Traffic key 
Key Privacy Key 


The PMK is used to generate the pairwise transient key (PTK), which in fact 
consists of three keys to be used for communication between an STA and AP after 
they have been mutually authenticated. To derive the PTK, the HMAC-SHA-1 
function is applied to the PMK, the MAC addresses of the STA and AP, and nonces 
generated when needed. Using the STA and AP addresses in the generation of the 
PTK provides protection against session hijacking and impersonation; using nonces 
provides additional random keying material. 
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The three parts of the PTK are as follows. 


e EAP Over LAN (EAPOL) Key Confirmation Key (EA POL-KCK): Supports 
the integrity and data origin authenticity of STA-to-AP control frames during 
operational setup of an RSN. It also performs an access control function: 
proof-of-possession of the PMK. An entity that possesses the PMK is autho- 
rized to use the link. 


e EAPOL Key Encryption Key (EAPOL-KEK): Protects the confidentiality of 
keys and other data during some RSN association procedures. 


e Temporal Key (TK): Provides the actual protection for user traffic. 


Group Keys Group keys are used for multicast communication in which one STA 
sends MPDU’s to multiple STAs. At the top level of the group key hierarchy is the 
group master key (GMK). The GMK is a key-generating key used with other inputs 
to derive the group temporal key (GTK). Unlike the PTK, which is generated using 
material from both AP and STA, the GTK is generated by the AP and transmitted 
to its associated STAs. Exactly how this GTK is generated is undefined. IEEE 
802.111, however, requires that its value is computationally indistinguishable from 
random. The GTK is distributed securely using the pairwise keys that are already 
established. The GTK is changed every time a device leaves the network. 


ParrwiIsE Key DisTRIBUTION The upper part of Figure 17.9 shows the MPDU 
exchange for distributing pairwise keys. This exchange is known as the 4-way 
handshake. The STA and SP use this handshake to confirm the existence of the 
PMK, verify the selection of the cipher suite, and derive a fresh PTK for the 
following data session. The four parts of the exchange are as follows. 


e AP —STA: Message includes the MAC address of the AP and a nonce 
(Anonce) 


e STA — AP: The STA generates its own nonce (Snonce) and uses both nonces 
and both MAC addresses, plus the PMK, to generate a PTK. The STA then 
sends a message containing its MAC address and Snonce, enabling the AP to 
generate the same PTK. This message includes a message integrity code (MIC)* 
using HMAC-MD5 or HMAC-SHA-1-128. The key used with the MIC is KCK. 


e AP —STA: The AP is now able to generate the PTK. The AP then sends a 
message to the STA, containing the same information as in the first message, 
but this time including a MIC. 


e STA — AP: This is merely an acknowledgment message, again protected by a 
MIC. 


Group Key DisTRIBUTION For group key distribution, the AP generates a GTK and 
distributes it to each STA in a multicast group. The two-message exchange with each 
STA consists of the following: 


e AP —STA: This message includes the GTK, encrypted either with RC4 or 
with AES. The key used for encryption is KEK. A MIC value is appended. 


?While MAC is commonly used in cryptography to refer to a Message Authentication Code, the term 
MIC is used instead in connection with 802.111 because MAC has another standard meaning, Media 
Access Control, in networking. 
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Figure 17.9 TEEE 802.111 Phases of Operation: Four-Way Handshake and Group Key 
Handshake 


e STA— AP: The STA acknowledges receipt of the GTK. This message 
includes a MIC value. 


Protected Data Transfer Phase 


IEEE 802.11i defines two schemes for protecting data transmitted in 802.11 
MPDUs: the Temporal Key Integrity Protocol (TKIP), and the Counter Mode-CBC 
MAC Protocol (CCMP). 
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TKIP TKIP is designed to require only software changes to devices that are 
implemented with the older wireless LAN security approach called Wired 
Equivalent Privacy (WEP). TKIP provides two services: 


e Message integrity: TKIP adds a message integrity code (MIC) to the 802.11 
MAC frame after the data field. The MIC is generated by an algorithm, called 
Michael, that computes a 64-bit value using as input the source and destination 
MAC address values and the Data field, plus key material. 


e Data confidentiality: Data confidentiality is provided by encrypting the 
MPDU plus MIC value using RC4. 


The 256-bit TK (Figure 17.8) is employed as follows. Two 64-bit keys are used 
with the Michael message digest algorithm to produce a message integrity code. 
One key is used to protect STA-to-AP messages, and the other key is used to protect 
AP-to-STA messages. The remaining 128 bits are truncated to generate the RC4 key 
used to encrypt the transmitted data. 

For additional protection, a monotonically increasing TKIP sequence counter 
(TSC) is assigned to each frame. The TSC serves two purposes. First, the TSC is 
included with each MPDU and is protected by the MIC to protect against replay 
attacks. Second, the TSC is combined with the session TK to produce a dynamic 
encryption key that changes with each transmitted MPDU, thus making cryptanaly- 
sis more difficult. 


CCMP CCMP is intended for newer IEEE 802.11 devices that are equipped with 
the hardware to support this scheme. As with TKIP, CCMP provides two services: 


e Message integrity: CCMP uses the cipher-block-chaining message authentica- 
tion code (CBC-MAC), described in Chapter 12. 


e Data confidentiality: CCMP uses the CTR block cipher mode of operation 
with AES for encryption. CTR is described in Chapter 6. 


The same 128-bit AES key is used for both integrity and confidentiality. The 
scheme uses a 48-bit packet number to construct a nonce to prevent replay 
attacks. 


The IEEE 802.111 Pseudorandom Function 


At a number of places in the IEEE 802.11i scheme, a pseudorandom function 
(PRF) is used. For example, it is used to generate nonces, to expand pairwise keys, 
and to generate the GTK. Best security practice dictates that different pseudoran- 
dom number streams be used for these different purposes. However, for implemen- 
tation efficiency, we would like to rely on a single pseudorandom number 
generator function. 

The PRF is built on the use of HMAC-SHA-1 to generate a pseudorandom bit 
stream. Recall that HMAC-SHA-1 takes a message (block of data) and a key of 
length at least 160 bits and produces a 160-bit hash value. SHA-1 has the property 
that the change of a single bit of the input produces a new hash value with no appar- 
ent connection to the preceding hash value. This property is the basis for pseudoran- 
dom number generation. 
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The IEEE 802.111 PRF takes four parameters as input and produces the 
desired number of random bits. The function is of the form PRF(K, A, B, Len), where 


K_ =asecret key 


A =a text string specific to the application (e.g., nonce generation or pair- 
wise key expansion) 
B =some data specific to each case 


Len = desired number of pseudorandom bits 


For example, for the pairwise transient key for CCMP: 


PTK = PRF(PMK, "Pairwise key expansion", min(AP- 
Addr, STA-Addr) || max(AP-Addr, STA-Addr) || min 
(Anonce, Snonce) || max(Anonce, Snonce) , 384) 


So, in this case, the parameters are 


K =PMK 
A =the text string "Pairwise key expansion" 
B =a sequence of bytes formed by concatenating the two MAC addresses 


and the two nonces 
Len = 384 bits 


Similarly, a nonce is generated by 
Nonce = PRF(RandomNumber, "Init Counter", MAC || Time, 256) 


where Time is a measure of the network time known to the nonce generator. 
The group temporal key is generated by 


GTK = PRF(GMK, "Group key expansion", MAC || Gnonce, 256) 


Figure 17.10 illustrates the function PRF(K, A, B, Len). The parameter K 
serves as the key input to HMAC. The message input consists of four items concate- 
nated together: the parameter A, a byte with value 0, the parameter B, and a counter i. 
The counter is initialized to 0. The HMAC algorithm is run once, producing a 160-bit 
hash value. If more bits are required, HMAC is run again with the same inputs, 
except that i is incremented each time until the necessary number of bits is gener- 
ated. We can express the logic as 


PRF(K, A, B, Len) 
R < null string 
for i < 0 to ((Len + 159)/160 - 1) do 
R < R|| HMAC-SHA-1(K, A |/0 |B |/2) 
Return Truncate-to-Len(R, Len) 
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R=HMAC-SHA-1(K,A I] 01 B Ili) 
Figure 17.10 TEEE 802.111 Pseudorandom Function 
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The Wireless Application Protocol (WAP) is a universal, open standard developed 
by the WAP Forum to provide mobile users of wireless phones and other wireless 
terminals such as pagers and personal digital assistants (PDAs) access to telephony 
and information services, including the Internet and the Web. WAP is designed to 
work with all wireless network technologies (e.g., GSM, CDMA, and TDMA). WAP 
is based on existing Internet standards, such as IP, XML, HTML, and HTTP, as much 
as possible. It also includes security facilities. At the time of this writing, the current 
release of the WAP specification is version 2.0. 

Strongly affecting the use of mobile phones and terminals for data services are 
the significant limitations of the devices and the networks that connect them. The 
devices have limited processors, memory, and battery life. The user interface is also 
limited, and the displays small. The wireless networks are characterized by relatively 
low bandwidth, high latency, and unpredictable availability and stability compared to 
wired connections. Moreover, all of these features vary widely from terminal device 
to terminal device and from network to network. Finally, mobile, wireless users have 
different expectations and needs from other information systems users. For instance, 
mobile terminals must be extremely easy to use — much easier than workstations 
and personal computers. WAP is designed to deal with these challenges. The WAP 
specification includes: 


e A programming model based on the WWW Programming Model 

e A markup language, the Wireless Markup Language, adhering to XML 

e A specification of a small browser suitable for a mobile, wireless terminal 
e A lightweight communications protocol stack 

e A framework for wireless telephony applications (WTAs) 
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Operational Overview 


The WAP Programming Model is based on three elements: the client, the gateway, and 
the original server (Figure 17.11). HTTP is used between the gateway and the original 
server to transfer content. The gateway acts as a proxy server for the wireless domain. 
Its processor(s) provide services that offload the limited capabilities of the hand-held, 
mobile, wireless terminals. For example, the gateway provides DNS services, converts 
between WAP protocol stack and the WWW stack (HTTP and TCP/IP), encodes infor- 
mation from the Web into a more compact form that minimizes wireless communica- 
tion, and in the other direction, decodes the compacted form into standard Web com- 
munication conventions. The gateway also caches frequently requested information. 

Figure 17.12 illustrates key components in a WAP environment. Using WAP, a 
mobile user can browse Web content on an ordinary Web server. The Web server 
provides content in the form of HTML-coded pages that are transmitted using the 
standard Web protocol stack (HTTP/TCP/IP). The HTML content must go through 
an HTML filter, which either may be colocated with the WAP proxy or in a separate 
physical module. The filter translates the HTML content into WML content. If the fil- 
ter is separate from the proxy, HTTP/TCP/IP is used to deliver the WML to the proxy. 
The proxy converts the WML to a more compact form known as binary WML and 
delivers it to the mobile user over a wireless network using the WAP protocol stack. 

If the Web server is capable of directly generating WML content, then the 
WML is delivered using HTTP/TCP/IP to the proxy, which converts the WML to 
binary WML and then delivers it to the mobile node using WAP protocols. 

The WAP architecture is designed to cope with the two principal limitations of 
wireless Web access: the limitations of the mobile node (small screen size, limited 
input capability) and the low data rates of wireless digital networks. Even with the 
introduction of 3G wireless networks, which provide broadband data rates, the small 
hand-held mobile nodes continue to have limited input and display capabilities. 
Thus, WAP or a similar capability will be needed for the indefinite future. 


Wireless Markup Language 


WML was designed to describe content and format for presenting data on devices with 
limited bandwidth, limited screen size, and limited user input capability. It is designed to 
work with telephone keypads, styluses, and other input devices common to mobile, 
wireless communication. WML permits the scaling of displays for use on two-line 
screens found in some small devices, as well as the larger screens found on smart phones. 


| Gateway | 


Encoded requests 


Requests 


Encoders 
and 
Decoders 


a 
Response (content) 


Encoded response 


Figure 17.11 The WAP Programming Model 
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Figure 17.12. WAP Infrastructure 


For an ordinary PC, a Web browser provides content in the form of Web pages 
coded with the Hypertext Markup Language (HTML). To translate an HTML- 
coded Web page into WML with content and format suitable for wireless devices, 
much of the information, especially graphics and animation, must be stripped away. 
WML presents mainly text-based information that attempts to capture the essence 
of the Web page and that is organized for easy access for users of mobile devices. 

Important features of WML include: 


e Text and image support: Formatting and layout commands are provided for 
text and limited image capability. 

¢ Deck/card organizational metaphor: WML documents are subdivided into 
small, well-defined units of user interaction called cards. Users navigate by 
moving back and forth between cards. A card specifies one or more units of 
interaction (a menu, a screen of text, or a text-entry field). A WML deck is 
similar to an HTML page in that it is identified by a Web address (URL) and 
is the unit of content transmission. 
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Support for navigation among cards and decks: WML includes provisions for 
event handling, which is used for navigation or executing scripts. 


In an HTML-based Web browser, a user navigates by clicking on links. At a 
WML-capable mobile device, a user interacts with cards, moving forward and back 
through the deck. 


Figure 17.13, from the WAP architecture document, illustrates the overall stack 
architecture implemented in a WAP client. In essence, this is a five-layer model. 
Each layer provides a set of functions and/or services to other services and applica- 
tions through a set of well-defined interfaces. Each of the layers of the architecture 
is accessible by the layers above, as well as by other services and applications. Many 
of the services in the stack may be provided by more than one protocol. For exam- 
ple, either HTTP or WSP may provide the Hypermedia Transfer service. 

Common to all five layers are sets of services that are accessible by multiple 
layers. These common services fall into two categories: security services and service 
discovery. 
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SecuriTy Services The WAP specification includes mechanisms to provide 
confidentiality, integrity, authentication, and nonrepudiation. The security services 
include the following. 


e Cryptographic libraries: This application framework level library provides ser- 
vices for signing of data for integrity and non-repudiation purposes. 


e Authentication: WAP provides various mechanisms for client and server 
authentication. At the Session Services layer, HTTP Client Authentication 
(RFC2617) may be used to authenticate clients to proxies and application 
servers. At the Transport Services layer, WTLS and TLS handshakes may be 
used to authenticate clients and servers. 


e Identity: The WAP Identity Module (WIM) provides the functions 
that store and process information needed for user identification and 
authentication. 


e PKI: The set of security services that enable the use and management of 
public-key cryptography and certificates. 


e Secure transport: The Transport Services layer protocols are defined for 
secure transport over datagrams and connections. WTLS is defined for secure 
transport over datagrams and TLS is defined for secure transport over 
connections (i.e., TCP). 


e Secure bearer: Some bearer networks provide bearer-level security. For 
example, IP networks (especially in the context of IPv6) provide bearer-level 
security with IPsec. 


SERVICE Discovery There is a collection of service discovery services that enable 
the WAP client and the Web server to determine capabilities and services. Examples 
of service discovery services include the following. 


e EFI: The External Functionality Interface (EFI) allows applications to 
discover what external functions/services are available on the device. 


e Provisioning: This service allows a device to be provisioned with the parame- 
ters necessary to access network services. 


e Navigation discovery: This service allows a device to discover new network 
services (e.g., secure pull proxies) during the course of navigation such as 
when downloading resources from a hypermedia server. The WAP Transport- 
Level End-to-End Security specification, described in Section 17.5, defines 
one navigation discovery protocol. 


e Service lookup: This service provides for the discovery of a service’s parame- 
ters through a directory lookup by name. One example of this is the Domain 
Name System (DNS). 


Wireless Application Environment 


The WAE specifies an application framework for wireless devices such as mobile 
telephones, pagers, and PDAs. In essence, the WAE consists of tools and formats 
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that are intended to ease the task of developing applications and devices supported 
by WAP. The major elements of the WAE model (Figure 17.13) are 


WAE user agents: Software that executes in the user’s wireless device and that 
provides specific functionality (e.g., display content) to the end user. 


Wireless telephony applications (WTA): A collection of telephony-specific 
extensions for call and feature control mechanisms that provide authors 
advanced mobile network services. Using WTA, applications developers can 
use the microbrowser to originate telephone calls and to respond to events 
from the telephone network. 


Standard content encoding: Defined to allow a WAE user agent (e.g., a 
browser) to conveniently navigate Web content. On the server side are content 
generators. These are applications (or services) on origin servers (e.g., CGI 
scripts) that produce standard content formats in response to requests from 
user agents in the mobile terminal. WAE does not specify any standard 
content generators but expects that there will be a variety available running 
on typical HTTP origin servers commonly used in WWW today. 


Push: A service to receive push transmissions from the server, i.e., transmis- 
sions that are not in response to a Web client request but are sent on the 
initiative of the server. This service is supported by the Push-OTA (Push Over 
The Air) session service. 


Multimedia messaging: Provides for the transfer and processing of multimedia 
messages, such as e-mail and instant messages, to WAP devices. 


WAP Protocol Architecture 


The WAP architecture illustrated in Figure 17.13 dictates a collection of services at 
each level and provides interface specifications at the boundary between each pair 
of layers. Because several of the services in the WAP stack can be provided using 
different protocols based on the circumstances, there are more than one possible 
stack configurations. Figure 17.14 depicts a common protocol stack configuration in 
which a WAP client device connects to a Web server via a WAP gateway. This con- 
figuration is common with devices that implement version 1 of the WAP specifica- 
tion but is also used in version 2 devices (WAP2) if the bearer network does not 
support TCP/IP. 


WAP Device WAP Gateway Web Server 


Figure 17.14 WTP 1.x Gateway 
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In the remainder of this subsection, we provide an overview of the WAP 
protocols, with the exception of WTLS, which is treated in Section 17.4. 


WIRELESS SESSION PRoTOCOL WSP provides applications with an interface for two 
session services. The connection-oriented session service operates above WTP, and the 
connectionless session service operates above the unreliable transport protocol WDP. 
In essence, WSP is based on HTTP with some additions and modifications to optimize 
its use over wireless channels. The principal limitations addressed are low data rate 
and susceptibility to loss of connection due to poor coverage or cell overloading. 

WSP is a transaction-oriented protocol based on the concept of a request and 
a reply. Each WSP protocol data unit (PDU) consists of a body, which may contain 
WML, WMLScript, or images; and a header, which contains information about the 
data in the body and about the transaction. WSP also defines a server push opera- 
tion, in which the server sends unrequested content to a client device. This may be 
used for broadcast messages or for services, such as news headlines or stock quotes, 
that may be tailored to each client device. 


WIRELESS TRANSACTION ProTrocoLt WTP manages transactions by conveying 
requests and responses between a user agent (such as a WAP browser) and an 
application server for such activities as browsing and e-commerce transactions. 
WTP provides a reliable transport service but dispenses with much of the overhead 
of TCP, resulting in a lightweight protocol that is suitable for implementation in 
“thin” clients (e.g., mobile nodes) and suitable for use over low-bandwidth wireless 
links. WTP includes the following features. 


e Three classes of transaction service. 


e Optional user-to-user reliability: WTP user triggers the confirmation of each 
received message. 

e Optional out-of-band data on acknowledgments. 

e PDU concatenation and delayed acknowledgment to reduce the number of 
messages sent. 


e Asynchronous transactions. 


WTP is transaction oriented rather than connection oriented. With WTP, there is 
no explicit connection setup or teardown but rather a reliable connectionless service. 

WTP provides three transaction classes that may be invoked by WSP or 
another higher layer protocol: 


e Class 0: Unreliable invoke message with no result message 


e Class 1: Reliable invoke message with no result message 


e Class 2: Unreliable invoke message with one reliable result message 


Class 0 provides an unreliable datagram service, which can be used for an unre- 
liable push operation. Data from a WTP user are encapsulated by WTP (the initiator, 
or client) in an invoke PDU and transmitted to the target WTP (the responder, or 
server) with no acknowledgment. The responder WTP delivers the data to the target 
WTP user. 
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Class 1 provides a reliable datagram service, which can be used for a reliable 
push operation. Data from an initiator are encapsulated in an invoke PDU and 
transmitted to the responder. The responder delivers the data to the target WTP 
user and acknowledges receipt of the data by sending back an ACK PDU to the 
WTP entity on the initiator side, which confirms the transaction to the source WTP 
user. The responder WTP maintains state information for some time after the ACK 
has been sent to handle possible retransmission of the ACK if it gets lost and/or the 
initiator retransmits the invoke PDU. 

Class 2 provides a request/response transaction service and supports the execu- 
tion of multiple transactions during one WSP session. Data from an initiator are 
encapsulated in an invoke PDU and transmitted to the responder, which delivers 
the data to the target WTP user. The target WTP user prepares response data, which 
are handed down to the local WTP entity. The responder WTP entity sends these data 
back in a result PDU. If there is a delay in generating the response data beyond a timer 
threshold, the responder may send an ACK PDU before sending the result PDU. This 
prevents the initiator from unnecessarily retransmitting the invoke message. 


WIRELESS DATAGRAM ProTocoL WDP is used to adapt a higher-layer WAP 
protocol to the communication mechanism (called the bearer) used between the 
mobile node and the WAP gateway. Adaptation may include partitioning data into 
segments of appropriate size for the bearer and interfacing with the bearer network. 
WDP hides details of the various bearer networks from the other layers of WAP. In 
some instances, WAP is implemented on top of IP. 
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WTLS provides security services between the mobile device (client) and the WAP 
gateway. WTLS is based on the industry-standard Transport Layer Security (TLS) 
Protocol,’ which is a refinement of the Secure Sockets Layer (SSL) protocol. TLS is 
the standard security protocol used between Web browsers and Web servers. WTLS 
is more efficient that TLS, requiring fewer message exchanges. To provide end-to- 
end security, WTLS is used between the client and the gateway, and TLS is used 
between the gateway and the target server (Figure 17.14). WAP systems translate 
between WTLS and TLS within the WAP gateway. Thus, the gateway is a point of 
vulnerability and must be given a high level of security from external attacks. 
WTLS provides the following features. 


e Data integrity: Uses message authentication to ensure that data sent between 
the client and the gateway are not modified. 

e Privacy: Uses encryption to ensure that the data cannot be read by a third party. 

e Authentication: Uses digital certificates to authenticate the two parties. 


e Denial-of-service protection: Detects and rejects messages that are replayed 
or not successfully verified. 


3See Chapter 16 for a discussion of SSL/TLS. However, the discussion in this section is self-contained; 
you do not need to read a description of TLS first. 
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WTLS Sessions and Connections 


Two important WTLS concepts are the secure session and the secure connection, 
which are defined in the specification as: 


e Secure connection: A connection is a transport (in the OSI layering model def- 
inition) that provides a suitable type of service. For SSL, such connections are 
peer-to-peer relationships. The connections are transient. Every connection is 
associated with one session. 


e Secure session: An SSL session is an association between a client and a server. 
Sessions are created by the Handshake Protocol. Sessions define a set of cryp- 
tographic security parameters, which can be shared among multiple connec- 
tions. Sessions are used to avoid the expensive negotiation of new security 
parameters for each connection. 


Between any pair of parties (applications such as HTTP on client and server), 
there may be multiple secure connections. In theory, there may also be multiple 
simultaneous sessions between parties, but this feature is not used in practice. 

There are a number of states associated with each session. Once a session is 
established, there is a current operating state for both read and write (i.e., receive 
and send). In addition, during the Handshake Protocol, pending read and write 
states are created. Upon successful conclusion of the Handshake Protocol, the 
pending states become the current states. 

A session state is defined by the following parameters: 


e Session identifier: An arbitrary byte sequence chosen by the server to identify 
an active or resumable session state. 


¢ Protocol version: WTLS protocol version number. 
e Peer certificate: Certificate of the peer. This element of the state may be null. 


e Compression method: The algorithm used to compress data prior to 
encryption. 


e Cipher spec: Specifies the bulk data encryption algorithm (such as null, 
RCS, DES, etc.) and a hash algorithm (such as MD5 or SHA-1) used for 
MAC calculation. It also defines cryptographic attributes such as the 
hash_size. 


e Master secret: A 20-byte secret shared between the client and server. 


e Sequence number: Which sequence numbering scheme (off, implicit, or 
explicit) is used in this secure connection. 


¢ Key refresh: Defines how often some connection state values (encryption key, 
MAC secret, and IV) calculations are performed. 


e Is resumable: A flag indicating whether the session can be used to initiate new 
connections. 


The connection state is the operating environment of the record protocol. It 
includes all parameters that are needed for the cryptographic operations (encryp- 
tion/decryption and MAC calculation/verification). Each secure connection has a 
connection state, which is defined by the following parameters. 
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e Connection end: Whether this entity is considered a client or a server in this 
secure session. 

e Bulk cipher algorithm: Includes the key size of this algorithm, how much of 
that key is secret, whether it is a block or stream cipher, and the block size of 
the cipher (if appropriate). 

e MAC algorithm: Includes the size of the key used for MAC calculation and 
the size of the hash which is returned by the MAC algorithm. 

e Compression algorithm: Includes all information the algorithm requires to do 
compression. 

e Master secret: A 20-byte secret shared between the client and server. 


Client random: A 16-byte value provided by the client. 
e Server random: A 16-byte value provided by the server. 


Sequence number mode: Which scheme is used to communicate sequence 
numbers in this secure connection. 


Key refresh: Defines how often some connection state parameters (encryption 
key, MAC secret, and IV) are updated. New keys are calculated at every 
p= Qs messages, that is, when the sequence number is 0, 2”, 3”, etc. 


WTLS Protocol Architecture 


WTLS is not a single protocol but rather two layers of protocols, as illustrated in 
Figure 17.15. The WTLS Record Protocol provides basic security services to various 
higher-layer protocols. In particular, the Hypertext Transfer Protocol (HTTP), 
which provides the transfer service for Web client/server interaction, can operate on 
top of WTLS. Three higher-layer protocols are defined as part of WTLS: the 
Handshake Protocol, The Change Cipher Spec Protocol, and the Alert Protocol. 
These WTLS-specific protocols are used in the management of WTLS exchanges 
and are examined subsequently in this section. 


WTLS RecorD ProrocoLt The WTLS Record Protocol takes user data from the 
next higher layer (WTP, WTLS Handshake Protocol, WTLS Alert Protocol, and 
WTLS Change Cipher Spec Protocol) and encapsulates these data in a PDU. The 
following steps occur (Figure 17.16). 


WTLS WTLS Change 
Handshake Cipher Spec | WTLS Alert 
Protocol Protocol Protocol 


WTLS Record Protocol | 
WDP or UDP/IP | 


Figure 17.15 WTLS Protocol Stack 
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Figure 17.16 WTLS Record Protocol Operation 


Step 1. The payload is compressed using a lossless compression algorithm. 


Step 2. A message authentication code (MAC) is computed over the compressed 


data, using HMAC. One of several hash algorithms can be used with HMAC, 
including MD-5 and SHA-1. The length of the hash code is 0, 5, or 10 bytes. 
The MAC is added after the compressed data. 


Step 3. The compressed message plus the MAC code are encrypted using a symmetric 


encryption algorithm. The allowable encryption algorithms are DES, triple 
DES, RCS, and IDEA. 


Step 4. The Record Protocol prepends a header to the encrypted payload. 


e 


e 


The Record Protocol header consists of the following fields (Figure 17.17). 


Record type (8 bits): Consisting of the subfields: 

—Record length field indicator (1 bit): Indicates whether a record length field 
is present. 

—Sequence number field indicator (1 bit): Indicates whether a sequence 
number field is present. 

—Cipher spec indicator (1 bit): If this bit is zero, it indicates that no compression, 
MAC protection, or encryption is used. 


—Content type (4 bits): The higher-layer protocol above the WTLS Record 
Protocol. 


Sequence number (16 bits): A sequence number associated with this record. 
This provides reliability over an unreliable transport service. 


Record length (16 bits): The length in bytes of the plaintext data (or compressed 
data if compression is used). 


CHANGE CIPHER SPEC ProToco. Associated with the current transaction is a 
cipher spec, which specifies the encryption algorithm, the hash algorithm used as 
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Figure 17.17 WTLS Record Format 


part of HMAC, and cryptographic attributes, such as MAC code size. There are 
two states associated with each session. Once a session is established, there is a 
current operating state for both read and write (1.e., receive and send). In addition, 
during the Handshake Protocol, pending read and write states are created. 

The Change Cipher Spec Protocol is one of the three WTLS-specific protocols 
that use the WTLS Record Protocol, and it is the simplest. This protocol consists of 
a single message, which consists of a single byte with the value 1. The sole purpose of 
this message is to cause the pending state to be copied into the current state, which 
updates the cipher suite to be used on this connection. Thus, when the Change 
Cipher Spec message arrives, the sender of the message sets the current write state 
to the pending state and the receiver sets the current read state to the pending state. 


ALERT ProTocot The Alert Protocol is used to convey WTLS-related alerts to the 
peer entity. As with other applications that use WTLS, alert messages are 
compressed and encrypted, as specified by the current state. 
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Each message in this protocol consists of 2 bytes. The first byte takes the value 
warning(1), critical(2), or fatal(3) to convey the severity of the message. The second 
byte contains a code that indicates the specific alert. If the level is fatal, WTLS 
immediately terminates the connection. Other connections on the same session may 
continue, but no new connections on this session may be established. A critical alert 
message results in termination of the current secure connection. Other connections 
using the secure session may continue and the secure identifier may also be used for 
establishing new secure connections. 

The connection is closed using the alert messages. Either party may initiate the 
exchange of the closing messages. If a closing message is received, then any data after 
this message is ignored. It is also required that the notified party verifies termination 
of the session by responding to the closing message. 

Error handling in the WTLS is based on the alert messages. When an error is 
detected, the detecting party sends an alert message containing the occurred error. 
Further procedures depend on the level of the error that occurred. 

Examples of fatal alerts: 


° session_close_notify: notifies the recipient that the sender will 
not send any more messages using this connection state or the secure 
session. 


° unexpected_message: An inappropriate message was received. 
° bad_record_mac: An incorrect MAC was received. 


e decompression_failure: The decompression function received 
improper input (e.g., unable to decompress or decompress to greater than 
maximum allowable length). 


e handshake_failure: Sender was unable to negotiate an acceptable set of 
security parameters given the options available. 


e illegal_parameter: A field in a handshake message was out of range or 
inconsistent with other fields. 
Examples of nonfatal alerts: 

° connection_close_notify: Notifies the recipient that the sender will 
not send any more messages using this connection state. 


e bad_certificate: A received certificate was corrupt (e.g., contained a sig- 
nature that did not verify). 


° unsupported_certificate: The type of the received certificate is not 
supported. 


° certificate_revoked: A certificate has been revoked by its signer. 

° certificate_expired: A certificate has expired. 

° certificate_unknown: Some other unspecified issue arose in processing 
the certificate, rendering it unacceptable. 


HANDSHAKE PRoTocoL The most complex part of WTLS is the Handshake 
Protocol. This protocol allows the server and client to authenticate each other and 
to negotiate an encryption and MAC algorithms and cryptographic keys to be 
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used to protect data sent in a WTLS record. The Handshake Protocol is used 
before any application data are transmitted. An important function of the 
Handshake Protocol is the generation of a pre-master secret, which in turn is used 
to generate a master secret. The master secret is then used to generate various 
cryptographic keys. 

The Handshake Protocol consists of a series of messages exchanged by client 
and server. Figure 17.18 shows the initial exchange needed to establish a logical 


Client Server 


Establish security capabilities, including 
protocol version, session ID, cipher suite, 
compression method, and initial random 
numbers. 


Server may send certificate, key exchange, 
and request certificate. Server signals end 
of hello message phase. 


Time 


Client sends certificate if requested. Client 
sends key exchange. Client may send 
certificate verification. 


Change cipher suite and finish 
handshake protocol. 


Note: Shaded transfers are 
optional or situation-dependent 
messages that are not always sent. 


Figure 17.18 WTLS Handshake Protocol Action 
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connection between client and server. The exchange can be viewed as having four 
phases. 

The first phase is used to initiate a logical connection and to establish the 
security capabilities that will be associated with it. The exchange is initiated by the 
client. The client sends a client_hello message that includes a session ID anda 
list of cryptographic and compression algorithms supported by the client (in 
decreasing order of preference for each algorithm type). After sending the 
client_hello message, the client waits for the server_hello message. This 
message indicates which cryptographic and compression algorithms will be used 
for the exchange. 

The second phase is used for server authentication and key exchange. The 
server begins this phase by sending its public-key certificate if it needs to be 
authenticated. Next, a server_key_exchange message may be sent if it is 
required. This message is needed for certain public-key algorithms used for 
symmetric key exchange. Next, the server can request a public-key certificate from 
the client, using the certificate_request message. The final message in phase 
2 (and one that is always required) is the server_hello_done message, which is 
sent by the server to indicate the end of the server hello and associated messages. 
After sending this message, the server will wait for a client response. This message 
has no parameters. 

The third phase is used for client authentication and key exchange. Upon 
receipt of the server_hello_done message, the client should verify that the 
server provided a valid certificate if required and check that the server_hello 
parameters are acceptable. If all is satisfactory, the client sends one or more mes- 
sages back to the server. If the server has requested a certificate, the client sends a 
certificate message. Next is the client_key_exchange message, which must be 
sent in this phase. The content of the message depends on the type of key exchange. 
Finally, in this phase, the client may senda certificate_verify message to pro- 
vide explicit verification of a client certificate. 

The fourth phase completes the setting up of a secure connection. The client 
sends a change_cipher_spec message and copies the pending CipherSpec 
into the current CipherSpec. Note that this message is not considered part of the 
Handshake Protocol but is sent using the Change Cipher Spec Protocol. The 
client then immediately sends the finished message under the new algorithms, 
keys, and secrets. The finished message verifies that the key exchange and 
authentication processes were successful. In response to these two messages, the 
server sends its own change_cipher_spec message, transfers the pending to 
the current CipherSpec, and sends its finished message. At this point, the hand- 
shake is complete, and the client and server may begin to exchange application 
layer data. 


Cryptographic Algorithms 


AUTHENTICATION Authentication in the WTLS is carried out with certificates. 
Authentication can occur either between the client and the server or when the client 
only authenticates the server. The latter procedure can happen only if the server 
allows it to occur. The server can require the client to authenticate itself to the server. 
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However, the WTLS specification defines that authentication is an optional 
procedure. Currently, X.509v3, X9.68, and WTLS certificates are supported. The 
WTILS certificate is optimized for size, and consists of the following elements 
(compare with Figure 14.14). 


Certificate_version: Version of the certificate. 
Signature_algorithm: Algorithm used to sign the certificate. 

Issuer: Defines the party who has signed the certificate, usually some CA. 
Valid_not_before: The beginning of validity period of the certificate. 
Valid_not_after: The point of time after the certificate is no longer valid. 
Subject: Owner of the key, associated with the public key being certified. 
Public_key_type: Type (algorithm) of the public key. 
Parameter_specifier: Specifies parameter relevant for the public key. 
Public key: The public key being certified. 

Signature: Signed with the CA’s private key. 


Key ExcHAnceE The purpose of the WTLS protocol is for the client and server to 
generate a mutually shared pre-master key. This key is then used to generate as 
master key, as explained subsequently. A number of key exchange protocols are 
supported by WTLS. They can be grouped into those protocols that include 
a server_key_exchange message as part of the Handshake Protocol 
(Figure 17.18) and those that don’t. 


The server_key_exchange message is sent by the server only when the 


server certificate message (if sent) does not contain enough data to allow the client 
to exchange a pre-master secret. The following three methods require the use of the 
server_key_exchange message. 


DH_anon: The conventional Diffie-Hellman computation is performed 
anonymously (without authentication). The negotiated key (Z) is used as the 
pre_master_secret. 


ECDH_anon: The elliptic curve Diffie-Hellman computation is performed. 
The negotiated key (Z) is used as the pre_master_secret. 


RSA_anon: This is an RSA key exchange without authentication. The server 
sends its RSA public key. In this method, a 20-byte secret value is generated 
by the client, encrypted under the server’s public key, and sent to the 
server. The server uses its private key to decrypt the secret value. The 
pre_master_secret is the secret value appended with the server’s 
public key. 


The server key exchange message is not sent for the following key exchange 


methods. 


ECDH_ECDSA: Elliptic curve Diffie-Hellman key exchange with ECDSA- 
based certificates. The server sends a certificate that contains its ECDH 
public key. The server certificate is signed with ECDSA by a third party 
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trusted by the client. Depending whether the client is to be authenticated or 
not, it sends its certificate containing its ECDH public key signed with 
ECDSA by a third party trusted by the server or just its (temporary) ECDH 
public key. Each party calculates the pre-master secret based on one’s own 
private key and counterpart’s public key received as such or contained in a 
certificate. 


e RSA: RSA key exchange with RSA-based certificates. The server sends a 
certificate that contains its RSA public key. The server certificate is signed 
with RSA by a third party trusted by the client. The client extracts the 
server’s public key from the received certificate, generates a secret value, 
encrypts it with the server’s public key, and sends it to the server. The pre- 
master secret is the secret value appended with the server’s public key. If the 
client is to be authenticated, it signs some data (messages sent during the 
handshake) with its RSA private key and sends its certificate and the signed 
data. 


PSEUDORANDOM FUNCTION(PRF) The PRF is used for a number of purposes in 
WTLS. The PRF takes as input a secret value, a seed, and an identifying label and 
produces an output of arbitrary length. In the TLS standard, two hash algorithms 
were used in order to make the PRF as secure as possible. In order to save 
resources, WTLS can be implemented using only one hash algorithm. Which hash 
algorithm is actually used is agreed on during the handshake as a part of the 
cipher spec. 
The PRF is based on the data expansion function 


P_hash(secret, seed) = HMAC_hash(secret, A(1) || seed) | 
HMAC_hash(secret, A(2) || seed) |] 
HMAC_hash(secret, A(3) || seed) ||... 


where || indicates concatenation and A() is defined as 


> 
Il 


seed 
HMAC _hash(secret, A(i - 1)) 


> 
Il 


Then, 
PRF(secret, label, seed) = P_hash(secret, label || seed) 


MASTER Key GENERATION The shared master secret is a one-time 20-byte value 
(160 bits) generated for this session by means of secure key exchange. The creation is in 
two stages. First,a pre_master_secret is exchanged. Second, the master_secret 
is calculated by both parties, using the function 
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master_secret = PRF(pre_master_secret, "master secret", 
ClientHello.random || ServerHello. random) 


where ClientHello.random and ServerHello.random are the random 
numbers exchanged during the first phase of the handshake protocol. 

The MAC and encryption keys are then derived from the master key. The 
MAC calculation uses the HMAC algorithm (Chapter 12) and encompasses the 
fields indicated in the expression 


HMAC_hash (MAC_secret, seq_number || WILSCompressed. 
record _type|| WILSCompressed.length || WwrLs 
Compressed. fragment) 


where WTLSCompressed. fragment refers to the (optionally) compressed plain- 
text data field. 
Either MD5 or SHA-1 may be used for the HMAC hash function. 
Encryption is applied to all of the WTLS record, except the header. The 
following encryption algorithms are permitted. 


Algorithm Key Size (bits) 
RCS 40, 56, 64, 128 
DES 192 
3DES 40 
IDEA 40, 56 


17.5 WAP END-TO-END SECURITY 


The basic WAP transmission model involving a WAP client, a WAP gateway, and 
a Web server results in a security gap, as illustrated in Figure 17.19. This figure corre- 
sponds to the protocol architecture shown in Figure 17.14. The mobile device estab- 
lishes a secure WTLS session with the WAP gateway. The WAP gateway, in turn, 


Wireless 
network 


Wired IP 
network 


WAP WAP Web 
device gateway server 


Figure 17.19 Security Zones Using Standard Security Services 


17.5 / WAP END-TO-END SECURITY 561 


establishes a secure SSL or TLS session with the Web server. Within the gateway, 
data are not encrypted during the translation process. The gateway is thus a point at 
which the data may be compromised. 

There are a number of approaches to providing end-to-end security 
between the mobile client and the Web server. In the WAP version 2 (known as 
WAP2) architecture document, the WAP forum defines several protocol arrange- 
ments that allow for end-to-end security. 

Version 1 of WAP assumed a simplified set of protocols over the wireless 
network and assumed that the wireless network did not support IP. WAP2 
provides the option for the mobile device to implement full TCP/IP-based 
protocols and operate over an IP-capable wireless network. Figure 17.20 
shows two ways in which this IP capability can be exploited to provide end-to- 
end security. In both approaches, the mobile client implements TCP/IP and 
HTTP. 

The first approach (Figure 17.20a) is to make use of TLS between client and 
server. A secure TLS session is set up between the endpoints. The WAP gateway 
acts as a TCP-level gateway and splices together two TCP connections to carry the 
traffic between the endpoints. However, the TCP user data field (TLS records) 
remains encrypted as it passes through the gateway, so end-to-end security is 
maintained. 


WAP Device Web Server 
HTTP WAP Gateway 


AE 
TLS 
TCP 


a 


(a) TLS-based security 


WAP Device Web Server 
WAP Gateway 
[ace noel 
ee aC 


Wireless Wireless Wired 


(b) IPSec-based security 


"Le iey, 


Figure 17.20 WAP2 End-to-End Security Approaches 
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Another possible approach is shown in Figure 17.20b. Here we assume that the 
WAP gateway acts as a simple Internet router. In this case, end-to-end security can 
be provided at the IP level using IPsec (discussed in Chapter 19). 

Yet another, somewhat more complicated, approach has been defined in 
more specific terms by the WAP forum in specification entitled “WAP Transport 
Layer End-to-End Security.” This approach is illustrated in Figure 17.21, which is 
based on a figure in [ASHLO1]. In this scenario, the WAP client connects to its 
usual WAP gateway and attempts to send a request through the gateway to a 
secure domain. The secure content server determines the need for security that 
requires that the mobile client connect to its local WAP gateway rather than its 
default WAP gateway. The Web server responds to the initial client request with an 
HTTP redirect message that redirects the client to a WAP gateway that is part of 
the enterprise network. This message passes back through the default gateway, 
which validates the redirect and sends it to the client. The client caches the redirect 
information and establishes a secure session with the enterprise WAP gateway 
using WTLS. After the connection is terminated, the default gateway is reselected 
and used for subsequent communication to other Web servers. Note that this 
approach requires that the enterprise maintain a WAP gateway on the wireless net- 
work that the client is using. 

Figure 17.22, from the WAP specification, illustrates the dialogue. 
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Figure 17.21 WAP2 End-to-End Security Scheme 


17.6 / RECOMMENDED READING AND WEB SITES 563 


Trusted 
Master/Default Secure SubordinateOS (Secure 
User User-Agent Pull Proxy OSs Pull Proxy Domain) 


Click: Bank 


GET: 
http://bank.com/... 
GET: 
http://bank.con/... 
Error 300: Body= XML Navigation Docume 


Validation 


Error 300: Body= KML Navigation Document 


CACHE: URL set tq secure proxy mapping 


Establish Secyre WTLS session (if ndt present) 


GET: http://bank.co: Lo. 


GET: 
http://bank.con/... 


Display wml deck 


Figure 17.22 WAP Transport Layer End-to-End Security Example 


17.6 RECOMMENDED READING AND WEB SITES 


The IEEE 802.11 and WiFi specifications are covered in more detail in [STALO7]. A good 
book-length treatment is [ROSH04]. [FRANO7] is an excellent, detailed treatment of IEEE 
802.111. [CHENOS] provides an overview of IEEE 802.111. 


CHENOS Chen, J.; Jiang, M.; and Liu, Y. “Wireless LAN Security and IEEE 802.111.” 
IEEE Wireless Communications, February 2005S. 

FRANO7 Frankel, S.; Eydt, B.; Owens, L.; and Scarfone, K. Establishing Wireless Robust 
Security Networks: A Guide to IEEE 802.11i. NIST Special Publication SP 800-97, 
February 2007. 


ROSH04_ Roshan, P., and Leary, J. 802.11 Wireless LAN Fundamentals. Indianapolis: 
Cisco Press, 2004. 


STALO7 Stallings, W. Data and Computer Communications, Eighth Edition. Upper 
Saddle River, NJ: Prentice Hall, 2007. 
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WS 


Recommended Web Sites: 


e The IEEE 802.11 Wireless LAN Working Group: Contains working group documents 
plus discussion archives. 


e Wi-Fi Alliance: An industry group promoting the interoperability of 802.11 products 
with each other and with Ethernet. 

e Wireless LAN Association: Gives an introduction to the technology, including a discus- 
sion of implementation considerations and case studies from users. Links to related sites. 

e Extensible Authentication Protocol (EAP) Working Group: IETF working group 
responsible for EAP and related issues. Site includes RFCs and Internet drafts. 


e Open Mobile Alliance: Consolidation of the WAP Forum and the Open Mobile 


Architecture Initiative. Provides WAP technical specifications and industry links. 


17.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


4-way handshake 

access point (AP) 

Alert Protocol 

basic service set (BSS) 

Change Cipher Spec 
Protocol 

Counter Mode-CBC MAC 
Protocol (CCMP) 

distribution system (DS) 


extended service set (ESS) 
group keys 

Handshake Protocol 
IEEE TSO2NEXe 

IEEE 802.11 


IEEE 802.111 
independent BSS (IBSS) 
logical link control (LLC) 


Review Questions 


media access control (MAC) 

MAC protocol data unit 
(MPDU) 

MAC service data unit 
(MSDU) 

message integrity code (MIC) 

Michael 

pairwise keys 

pseudorandom function 

Robust Security Network 
(RSN) 

Temporal Key Integrity 
Protocol (TKIP) 

Wired Equivalent Privacy 
(WEP) 

Wireless Application 
Environment (WAE) 


Wireless Application Protocol 
(WAP) 

Wireless Datagram Protocol 
(WDP) 

wireless LAN (WLAN) 

Wireless Markup Language 
(WML) 

Wireless Session Protocol 
(WSP) 

Wireless Transaction Protocol 
(WTP) 

Wireless Transport Layer 
Security (WTLS) 

Wi-Fi 

Wi-Fi Protected Access 
(WPA) 

WTLS Record Protocol 


17.1 What is the basic building block of an 802.11 WLAN? 
17.2 Define an extended service set. 

17.3 List and briefly define IEEE 802.11 services. 
17.4 Isa distribution system a wireless network? 
17.5 Howis the concept of an association related to that of mobility? 
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17.6 What security areas are addressed by IEEE 802.111? 
17.7 Briefly describe the four IEEE 802.111 phases of operation. 
17.8 What is the difference between TKIP and CCMP? 
17.9 What is the difference between an HTML filter and a WAP proxy? 
17.10 What services are provided by WSP? 
17.11 When would each of the three WTP transaction classes be used? 
17.12 List and briefly define the security services provided by WTLS. 
17.13 Briefly describe the four protocol elements of WTLS. 
17.14 List and briefly define all of the keys used in WTLS. 
17.15 Describe three alternative approaches to providing WAP end-to-end security. 
Problems 
17.1 In IEEE 802.11, open system authentication simply consists of two commu- 
nications. An authentication is requested by the client, which contains the 
station ID (typically the MAC address). This is followed by an authentica- 
tion response from the AP/router containing a success or failure message. 
An example of when a failure may occur is if the client’s MAC address is 
explicitly excluded in the AP/router configuration. 
a. What are the benefits of this authentication scheme? 
b. What are the security vulnerabilities of this authentication scheme? 
17.2. Prior to the introduction of IEEE 802.111, the security scheme for IEEE 


802.11 was Wired Equivalent Privacy (WEP). WEP assumed all devices in 
the network share a secret key. The purpose of the authentication scenario is 
for the STA to prove that it possesses the secret key. Authentication pro- 
ceeds as shown in Figure 17.23. The STA sends a message to the AP request- 
ing authentication. The AP issues a challenge, which is a sequence of 128 
random bytes sent as plaintext. The STA encrypts the challenge with the 
shared key and returns it to the AP. The AP decrypts the incoming value and 
compares it to the challenge that it sent. If there is a match, the AP confirms 
that authentication has succeeded. 


STA AP 
Station sends a request Request 
for authentication. ee 
AP sends challenge message 
challenke containing 128-bit random 
number. 
; Station responds Response 
with encrypted version 
of challenge number. 
Success AP decrypts challenge response. 


If match, send authentication 
success message. 


Figure 17.23. WEP Authentication 
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17.4 


17.5 


17.6 


a. What are the benefits of this authentication scheme? 
b. This authentication scheme is incomplete. What is missing and why is this impor- 

tant? Hint: The addition of one or two messages would fix the problem. 
c. What is a cryptographic weakness of this scheme? 
For WEP, data integrity and data confidentiality are achieved using the RC4 stream 
encryption algorithm. The transmitter of an MPDU performs the following steps, 
referred to as encapsulation: 

1. The transmitter selects an initial vector (IV) value. 


2. The IV value is concatenated with the WEP key shared by transmitter and 
receiver to form the seed, or key input, to RC4. 


. A 32-bit cyclic redundancy check (CRC) is computed over all the bits of the 
MAC data field and appended to the data field. The CRC is a common 
error-detection code used in data link control protocols. In this case, the 
CRC serves as a integrity check value (ICV). 


. The result of step 3 is encrypted using RC4 to form the ciphertext block. 


. The plaintext IV is prepended to the ciphertext block to form the encapsu- 
lated MPDU for transmission. 
a. Draw a block diagram that illustrates the encapsulation process. 
b. Describe the steps at the receiver end to recover the plaintext and per- 
form the integrity check. 
c. Draw a block diagram that illustrates part b. 


A potential weakness of the CRC as an integrity check is that it is a linear function. 
This means that you can predict which bits of the CRC are changed if a single bit of 
the message is changed. Furthermore, it is possible to determine which combination 
of bits could be flipped in the message so that the net result is no change in the CRC. 
Thus, there are a number of combinations of bit flippings of the plaintext message 
that leave the CRC unchanged, so message integrity is defeated. However, in WEP, if 
an attacker does not know the encryption key, the attacker does not have access to 
the plaintext, only to the ciphertext block. Does this mean that the ICV is protected 
from the bit flipping attack? Explain. 

One potential weakness in WTLS is the use of CBC mode cipher encryption. The 
standard states that for CBC mode block ciphers, the IV (initialization vector) for 
each record is calculated in the following way: record_IV = IV @ S, where IV is the 
original IV and S is obtained by concatenating the 2-byte sequence number of the 
record the needed number of times to obtain as many bytes as in IV. Thus, if the IV is 
8 bytes long, the sequence number of the record is concatenated with itself four times. 
Now, in CBC mode, the first block of plaintext for a record with sequence number i 
would be encrypted as (Figure 6.4) 


C, = E(K, UV @S@ Ps,1]) 


where P,,; is the first block of plaintext of a record with sequence number s and S is 
the concatenated version of s. Consider a terminal application (such as telnet), where 
each keypress is sent as an individual record. Alice enters her password into this 
application, and Eve captures these encrypted records. Note that the sequence 
number is known to Eve, because this portion of the record is not encrypted 
(Figure 17.17). Now somehow Eve gets hold of Alice’s channel, perhaps through an 
echo feature in some application. This means that Eve can present unencrypted 
records to the channel and view the encrypted result. Suggest a brute-force method 
by which Eve can guess password letters in Alice’s password. Hint: Exploit these 
properties of exclusive-OR:x @x = Lxa@l =x. 

An earlier version of WTLS supported a 40-bit XOR MAC and also supported RC4 
stream encryption. The XOR MAC works by padding the message with zeros, divid- 
ing it into 5-byte blocks and XORing these blocks together. Show that this scheme 
does not provide message integrity protection. 
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Despite the refusal of VADM Poindexter and LtCol North to appear, the Board’s 
access to other sources of information filled much of this gap. The FBI provided 
documents taken from the files of the National Security Advisor and relevant 
NSC staff members, including messages from the PROF system between VADM 
Poindexter and LtCol North. The PROF messages were conversations by com- 
puter, written at the time events occurred and presumed by the writers to be pro- 
tected from disclosure. In this sense, they provide a first-hand, contemporaneous 
account of events. 


—The Tower Commission Report to President Reagan on the 
Iran-Contra Affair, 1987 


KEY POINTS 


® PGP is an open-source, freely available software package for e-mail secu- 
rity. It provides authentication through the use of digital signature, confi- 
dentiality through the use of symmetric block encryption, compression 
using the ZIP algorithm, and e-mail compatibility using the radix-64 
encoding scheme. 


® PGP incorporates tools for developing a public-key trust model and 
public-key certificate management. 

® S/MIME is an Internet standard approach to e-mail security that incorporates 
the same functionality as PGP. 

® DKIM is a specification used by e-mail providers for cryptographically 
signing e-mail messages on behalf of the source domain. 


In virtually all distributed environments, electronic mail is the most heavily 
used network-based application. Users expect to be able to, and do, send 
e-mail to others who are connected directly or indirectly to the Internet, 
regardless of host operating system or communications suite. With the explo- 
sively growing reliance on e-mail, there grows a demand for authentication 
and confidentiality services. Two schemes stand out as approaches that enjoy 
widespread use: Pretty Good Privacy (PGP) and S/MIME. Both are examined 
in this chapter. The chapter closes with a discussion of DomainKeys Identified 
Mail. 


18.1 PRETTY GOOD PRIVACY 


PGP is a remarkable phenomenon. Largely the effort of a single person, Phil 
Zimmermann, PGP provides a confidentiality and authentication service that can 
be used for electronic mail and file storage applications. In essence, Zimmermann 
has done the following: 
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1. Selected the best available cryptographic algorithms as building blocks. 


2. Integrated these algorithms into a general-purpose application that is inde- 
pendent of operating system and processor and that is based on a small set of 
easy-to-use commands. 


3. Made the package and its documentation, including the source code, freely 
available via the Internet, bulletin boards, and commercial networks such as 
AOL (America On Line). 


4. Entered into an agreement with a company (Viacrypt, now Network 
Associates) to provide a fully compatible, low-cost commercial version of PGP. 


PGP has grown explosively and is now widely used. A number of reasons can 
be cited for this growth. 


1. It is available free worldwide in versions that run on a variety of platforms, 
including Windows, UNIX, Macintosh, and many more. In addition, the commer- 
cial version satisfies users who want a product that comes with vendor support. 


nN 


. Itis based on algorithms that have survived extensive public review and are con- 
sidered extremely secure. Specifically, the package includes RSA, DSS, and 
Diffie-Hellman for public-key encryption; CAST-128, IDEA, and 3DES for sym- 
metric encryption; and SHA-1 for hash coding. 


3. It has a wide range of applicability, from corporations that wish to select and 
enforce a standardized scheme for encrypting files and messages to individuals 
who wish to communicate securely with others worldwide over the Internet and 
other networks. 

4. It was not developed by, nor is it controlled by, any governmental or standards 
organization. For those with an instinctive distrust of “the establishment,” this 
makes PGP attractive. 

. PGP is now on an Internet standards track (RFC 3156; MIME Security with 
OpenPGP). Nevertheless, PGP still has an aura of an antiestablishment 
endeavor. 


mn 


We begin with an overall look at the operation of PGP. Next, we examine 
how cryptographic keys are created and stored. Then, we address the vital issue of 
public-key management. 


Notation 


Most of the notation used in this chapter has been used before, but a few terms are new. 
It is perhaps best to summarize those at the beginning. The following symbols are used. 


K, = session key used in symmetric encryption scheme 

PR, = private key of user A, used in public-key encryption scheme 
PU, = public key of user A, used in public-key encryption scheme 
EP = public-key encryption 

DP = public-key decryption 

EC = symmetric encryption 

DC = symmetric decryption 
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H_ = hash function 
|| = concatenation 
Z = compression using ZIP algorithm 


R64 = conversion to radix 64 ASCII format! 


The PGP documentation often uses the term secret key to refer to a key paired 
with a public key in a public-key encryption scheme. As was mentioned earlier, this 
practice risks confusion with a secret key used for symmetric encryption. Hence, we 
use the term private key instead. 


Operational Description 


The actual operation of PGP, as opposed to the management of keys, consists of four 
services: authentication, confidentiality, compression, and e-mail compatibility 
(Table 18.1). We examine each of these in turn. 


AUTHENTICATION Figure 18.1a illustrates the digital signature service provided by 
PGP. This is the digital signature scheme discussed in Chapter 13 and illustrated in 
Figure 13.2. The sequence is as follows. 

1. The sender creates a message. 

2. SHA-1 is used to generate a 160-bit hash code of the message. 


3. The hash code is encrypted with RSA using the sender’s private key, and the 
result is prepended to the message. 


4. The receiver uses RSA with the sender’s public key to decrypt and recover the 
hash code. 


5. The receiver generates a new hash code for the message and compares it with 
the decrypted hash code. If the two match, the message is accepted as authentic. 


Table 18.1 Summary of PGP Services 


Function Algorithms Used Description 


A hash code of a message is created using 
Digital DSS/SHA or RSA/SHA SHA-1. This message digest is encrypted using 
signature DSS or RSA with the sender’s private key and 
included with the message. 


A message is encrypted using CAST-128 or 
CAST or IDEA or Three-key IDEA or 3DES with a one-time session key 
Triple DES with Diffie-Hellman | generated by the sender. The session key is 
or RSA encrypted using Diffie-Hellman or RSA with 
the recipient’s public key and included with 
the message. 


Message 
encryption 


A message may be compressed for storage or 


Compression toe g 
P transmission using ZIP. 


To provide transparency for e-mail applica- 
Radix-64 conversion tions, an encrypted message may be converted 
to an ASCII string using radix-64 conversion. 


E-mail 
compatibility 


' The American Standard Code for Information Interchange (ASCII) is described in Appendix Q. 


TLS 


Source A _—_———_ Destination B ——— 


PU, 


E[PR,, H(M)] 


(a) Authentication only 


E[PU,, Ks] 


Compare 


(c) Confidentiality and authentication 


Figure 18.1 PGP Cryptographic Functions 
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The combination of SHA-1 and RSA provides an effective digital signature 
scheme. Because of the strength of RSA, the recipient is assured that only the pos- 
sessor of the matching private key can generate the signature. Because of the 
strength of SHA-1, the recipient is assured that no one else could generate a new 
message that matches the hash code and, hence, the signature of the original 
message. 

As an alternative, signatures can be generated using DSS/SHA-1. 

Although signatures normally are found attached to the message or file that 
they sign, this is not always the case: Detached signatures are supported. A detached 
signature may be stored and transmitted separately from the message it signs. This is 
useful in several contexts. A user may wish to maintain a separate signature log of all 
messages sent or received. A detached signature of an executable program can 
detect subsequent virus infection. Finally, detached signatures can be used when 
more than one party must sign a document, such as a legal contract. Each person’s 
signature is independent and therefore is applied only to the document. Otherwise, 
signatures would have to be nested, with the second signer signing both the docu- 
ment and the first signature, and so on. 


CONFIDENTIALITY Another basic service provided by PGP is confidentiality, which 
is provided by encrypting messages to be transmitted or to be stored locally as files. 
In both cases, the symmetric encryption algorithm CAST-128 may be used. 
Alternatively, IDEA or 3DES may be used. The 64-bit cipher feedback (CFB) mode 
is used. 

As always, one must address the problem of key distribution. In PGP, each 
symmetric key is used only once. That is, a new key is generated as a random 128-bit 
number for each message. Thus, although this is referred to in the documentation as 
a session key, it is in reality a one-time key. Because it is to be used only once, the 
session key is bound to the message and transmitted with it. To protect the key, it is 
encrypted with the receiver’s public key. Figure 18.1b illustrates the sequence, which 
can be described as follows. 


1. The sender generates a message and a random 128-bit number to be used as 
a session key for this message only. 


2. The message is encrypted using CAST-128 (or IDEA or 3DES) with the ses- 
sion key. 

3. The session key is encrypted with RSA using the recipient’s public key and is 
prepended to the message. 


4. The receiver uses RSA with its private key to decrypt and recover the session 
key. 
5. The session key is used to decrypt the message. 


As an alternative to the use of RSA for key encryption, PGP provides an 
option referred to as Diffie-Hellman. As was explained in Chapter 10, Diffie- 
Hellman is a key exchange algorithm. In fact, PGP uses a variant of Diffie-Hellman 
that does provide encryption/decryption, known as ElGamal (Chapter 10). 

Several observations may be made. First, to reduce encryption time, the combi- 
nation of symmetric and public-key encryption is used in preference to simply using 
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RSA or ElGamal to encrypt the message directly: CAST-128 and the other symmet- 
ric algorithms are substantially faster than RSA or ElGamal. Second, the use of the 
public-key algorithm solves the session-key distribution problem, because only the 
recipient is able to recover the session key that is bound to the message. Note that 
we do not need a session-key exchange protocol of the type discussed in Chapter 14, because 
we are not beginning an ongoing session. Rather, each message is a one-time inde- 
pendent event with its own key. Furthermore, given the store-and-forward nature of 
electronic mail, the use of handshaking to assure that both sides have the same 
session key is not practical. Finally, the use of one-time symmetric keys strengthens 
what is already a strong symmetric encryption approach. Only a small amount of 
plaintext is encrypted with each key, and there is no relationship among the keys. 
Thus, to the extent that the public-key algorithm is secure, the entire scheme is 
secure. To this end, PGP provides the user with a range of key size options from 768 
to 3072 bits (the DSS key for signatures is limited to 1024 bits). 


CONFIDENTIALITY AND AUTHENTICATION As Figure 18.1c illustrates, both services 
may be used for the same message. First, a signature is generated for the plaintext 
message and prepended to the message. Then the plaintext message plus signature is 
encrypted using CAST-128 (or IDEA or 3DES), and the session key is encrypted 
using RSA (or ElGamal). This sequence is preferable to the opposite: encrypting 
the message and then generating a signature for the encrypted message. It is 
generally more convenient to store a signature with a plaintext version of a message. 
Furthermore, for purposes of third-party verification, if the signature is performed 
first, a third party need not be concerned with the symmetric key when verifying the 
signature. 

In summary, when both services are used, the sender first signs the message 
with its own private key, then encrypts the message with a session key, and finally 
encrypts the session key with the recipient’s public key. 


Compression As a default, PGP compresses the message after applying the 
signature but before encryption. This has the benefit of saving space both for e-mail 
transmission and for file storage. 

The placement of the compression algorithm, indicated by Z for compression 
and Z! for decompression in Figure 18.1, is critical. 


1. The signature is generated before compression for two reasons: 


a. It is preferable to sign an uncompressed message so that one can store only 
the uncompressed message together with the signature for future verifica- 
tion. If one signed a compressed document, then it would be necessary either 
to store a compressed version of the message for later verification or to 
recompress the message when verification is required. 


b. Even if one were willing to generate dynamically a recompressed message 
for verification, PGP’s compression algorithm presents a difficulty. The algo- 
rithm is not deterministic; various implementations of the algorithm achieve 
different tradeoffs in running speed versus compression ratio and, as a result, 
produce different compressed forms. However, these different compression 
algorithms are interoperable because any version of the algorithm can 
correctly decompress the output of any other version. Applying the hash 
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function and signature after compression would constrain all PGP imple- 
mentations to the same version of the compression algorithm. 


2. Message encryption is applied after compression to strengthen cryptographic 
security. Because the compressed message has less redundancy than the 
original plaintext, cryptanalysis is more difficult. 


The compression algorithm used is ZIP, which is described in Appendix O. 


E-maiL Compatisitiry When PGP is used, at least part of the block to be transmitted 
is encrypted. If only the signature service is used, then the message digest is 
encrypted (with the sender’s private key). If the confidentiality service is used, the 
message plus signature (if present) are encrypted (with a one-time symmetric key). 
Thus, part or all of the resulting block consists of a stream of arbitrary 8-bit octets. 
However, many electronic mail systems only permit the use of blocks consisting of 
ASCII text. To accommodate this restriction, PGP provides the service of converting 
the raw 8-bit binary stream to a stream of printable ASCII characters. 

The scheme used for this purpose is radix-64 conversion. Each group of three 
octets of binary data is mapped into four ASCII characters. This format also 
appends a CRC to detect transmission errors. See Appendix 18A for a description. 

The use of radix 64 expands a message by 33%. Fortunately, the session key 
and signature portions of the message are relatively compact, and the plaintext mes- 
sage has been compressed. In fact, the compression should be more than enough to 
compensate for the radix-64 expansion. For example, [HELD96] reports an average 
compression ratio of about 2.0 using ZIP. If we ignore the relatively small signature 
and key components, the typical overall effect of compression and expansion of a 
file of length X would be 1.33 X 0.5 x X = 0.665 x X.Thus, there is still an overall 
compression of about one-third. 

One noteworthy aspect of the radix-64 algorithm is that it blindly converts the 
input stream to radix-64 format regardless of content, even if the input happens to 
be ASCII text. Thus, if a message is signed but not encrypted and the conversion is 
applied to the entire block, the output will be unreadable to the casual observer, 
which provides a certain level of confidentiality. As an option, PGP can be config- 
ured to convert to radix-64 format only the signature portion of signed plaintext 
messages. This enables the human recipient to read the message without using PGP. 
PGP would still have to be used to verify the signature. 

Figure 18.2 shows the relationship among the four services so far discussed. 
On transmission (if it is required), a signature is generated using a hash code of the 
uncompressed plaintext. Then the plaintext (plus signature if present) is com- 
pressed. Next, if confidentiality is required, the block (compressed plaintext or com- 
pressed signature plus plaintext) is encrypted and prepended with the public-key- 
encrypted symmetric encryption key. Finally, the entire block is converted to 
radix-64 format. 

On reception, the incoming block is first converted back from radix-64 format 
to binary. Then, if the message is encrypted, the recipient recovers the session key 
and decrypts the message. The resulting block is then decompressed. If the message 
is signed, the recipient recovers the transmitted hash code and compares it to its 
own calculation of the hash code. 
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Figure 18.2 Transmission and Reception of PGP Messages 
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Cryptographic Keys and Key Rings 


PGP makes use of four types of keys: one-time session symmetric keys, public keys, 
private keys, and passphrase-based symmetric keys (explained subsequently). Three 
separate requirements can be identified with respect to these keys. 


1. A means of generating unpredictable session keys is needed. 


2. We would like to allow a user to have multiple public-key/private-key pairs. One 
reason is that the user may wish to change his or her key pair from time to time. 
When this happens, any messages in the pipeline will be constructed with an 
obsolete key. Furthermore, recipients will know only the old public key until an 
update reaches them. In addition to the need to change keys over time, a user 
may wish to have multiple key pairs at a given time to interact with different 
groups of correspondents or simply to enhance security by limiting the amount of 
material encrypted with any one key. The upshot of all this is that there is not a 
one-to-one correspondence between users and their public keys. Thus, some 
means is needed for identifying particular keys. 


3. Each PGP entity must maintain a file of its own public/private key pairs as 
well as a file of public keys of correspondents. 


We examine each of these requirements in turn. 


SESSION KEY GENERATION Each session key is associated with a single message and 
is used only for the purpose of encrypting and decrypting that message. Recall that 
message encryption/decryption is done with a symmetric encryption algorithm. 
CAST-128 and IDEA use 128-bit keys; 3DES uses a 168-bit key. For the following 
discussion, we assume CAST-128. 

Random 128-bit numbers are generated using CAST-128 itself. The input to 
the random number generator consists of a 128-bit key and two 64-bit blocks that 
are treated as plaintext to be encrypted. Using cipher feedback mode, the CAST-128 
encrypter produces two 64-bit cipher text blocks, which are concatenated to form 
the 128-bit session key. The algorithm that is used is based on the one specified in 
ANSI X12.17. 

The “plaintext” input to the random number generator, consisting of two 
64-bit blocks, is itself derived from a stream of 128-bit randomized numbers. These 
numbers are based on keystroke input from the user. Both the keystroke timing and 
the actual keys struck are used to generate the randomized stream. Thus, if the user 
hits arbitrary keys at his or her normal pace, a reasonably “random” input will 
be generated. This random input is also combined with previous session key output 
from CAST-128 to form the key input to the generator. The result, given the 
effective scrambling of CAST-128, is to produce a sequence of session keys that is 
effectively unpredictable. 

Appendix P discusses PGP random number generation techniques in more 
detail. 


Key IDENTIFIERS As we have discussed, an encrypted message is accompanied by 
an encrypted form of the session key that was used for message encryption. The 
session key itself is encrypted with the recipient’s public key. Hence, only the 
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recipient will be able to recover the session key and therefore recover the message. 
If each user employed a single public/private key pair, then the recipient would 
automatically know which key to use to decrypt the session key: the recipient’s 
unique private key. However, we have stated a requirement that any given user may 
have multiple public/private key pairs. 

How, then, does the recipient know which of its public keys was used to 
encrypt the session key? One simple solution would be to transmit the public key 
with the message. The recipient could then verify that this is indeed one of its public 
keys, and proceed. This scheme would work, but it is unnecessarily wasteful of space. 
An RSA public key may be hundreds of decimal digits in length. Another solution 
would be to associate an identifier with each public key that is unique at least within 
one user. That is, the combination of user ID and key ID would be sufficient to iden- 
tify a key uniquely. Then only the much shorter key ID would need to be transmit- 
ted. This solution, however, raises a management and overhead problem: Key IDs 
must be assigned and stored so that both sender and recipient could map from key 
ID to public key. This seems unnecessarily burdensome. 

The solution adopted by PGP is to assign a key ID to each public key that is, 
with very high probability, unique within a user ID.” The key ID associated with 
each public key consists of its least significant 64 bits. That is, the key ID of public 
key PU, is (PU, mod 2™). This is a sufficient length that the probability of duplicate 
key IDs is very small. 

A key ID is also required for the PGP digital signature. Because a sender may 
use one of a number of private keys to encrypt the message digest, the recipient 
must know which public key is intended for use. Accordingly, the digital signature 
component of a message includes the 64-bit key ID of the required public key. When 
the message is received, the recipient verifies that the key ID is for a public key that 
it knows for that sender and then proceeds to verify the signature. 

Now that the concept of key ID has been introduced, we can take a more 
detailed look at the format of a transmitted message, which is shown in Figure 18.3. 
A message consists of three components: the message component, a signature 
(optional), and a session key component (optional). 

The message component includes the actual data to be stored or transmitted, 
as well as a filename and a timestamp that specifies the time of creation. 

The signature component includes the following. 


e Timestamp: The time at which the signature was made. 


e Message digest: The 160-bit SHA-1 digest encrypted with the sender’s private 
signature key. The digest is calculated over the signature timestamp concate- 
nated with the data portion of the message component. The inclusion of the 
signature timestamp in the digest insures against replay types of attacks. The 
exclusion of the filename and timestamp portions of the message component 
ensures that detached signatures are exactly the same as attached signatures 


?We have seen this introduction of probabilistic concepts before, in Section 8.3, for determining whether 
a number is prime. It is often the case in designing algorithms that the use of probabilistic techniques 
results in a less time-consuming, a less complex solution, or both. 
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Content Operation 
Key ID of recipient's 
Session key public key (PU,) 
component 
P Session key (K,) E(PU,, °) 
Timestamp 
Key ID of sender's 
Signature public key (PU,) 
Leading two octets 
of message digest 
E(PR,; *) 
R64 
ZIP E(K,, *) 
Message 
Notation: 
E(PU,, *) = encryption with user b's public key 
E(PR,, *) = encryption with user a's private key 
E(K,,*) |= encryption with session key 
ZIP = Zip compression function 
R64 = Radix-64 conversion function 


Figure 18.3 General Format PGP Message (from A to B) 


prefixed to the message. Detached signatures are calculated on a separate file 
that has none of the message component header fields. 


Leading two octets of message digest: Enables the recipient to determine if 
the correct public key was used to decrypt the message digest for authentica- 
tion by comparing this plaintext copy of the first two octets with the first two 
octets of the decrypted digest. These octets also serve as a 16-bit frame check 
sequence for the message. 


Key ID of sender’s public key: Identifies the public key that should be used to 
decrypt the message digest and, hence, identifies the private key that was used 
to encrypt the message digest. 


The message component and optional signature component may be com- 


pressed using ZIP and may be encrypted using a session key. 
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The session key component includes the session key and the identifier of the 
recipient’s public key that was used by the sender to encrypt the session key. 
The entire block is usually encoded with radix-64 encoding. 


Key Rincs We have seen how key IDs are critical to the operation of PGP and that 
two key IDs are included in any PGP message that provides both confidentiality 
and authentication. These keys need to be stored and organized in a systematic way 
for efficient and effective use by all parties. The scheme used in PGP is to provide a 
pair of data structures at each node, one to store the public/private key pairs owned 
by that node and one to store the public keys of other users known at this node. 
These data structures are referred to, respectively, as the private-key ring and the 
public-key ring. 

Figure 18.4 shows the general structure of a private-key ring. We can view the 
ring as a table in which each row represents one of the public/private key pairs 
owned by this user. Each row contains the entries: 


e Timestamp: The date/time when this key pair was generated. 

e Key ID: The least significant 64 bits of the public key for this entry. 

e Public key: The public-key portion of the pair. 

e Private key: The private-key portion of the pair; this field is encrypted. 


Private-Key Ring 


Timestamp Key ID* Public Key Encrypted User ID* 
Private Key 


e 


PU; mod 2 


* = field used to index table 


Figure 
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8.4 General Structure of Private- and Public-Key Rings 
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¢ User ID: Typically, this will be the user’s e-mail address (e.g., stallings@acm.org). 
However, the user may choose to associate a different name with each pair 
(e.g., Stallings, WStallings, WilliamStallings, etc.) or to reuse the same User ID 
more than once. 


The private-key ring can be indexed by either User ID or Key ID; later we will 
see the need for both means of indexing. 

Although it is intended that the private-key ring be stored only on the 
machine of the user that created and owns the key pairs and that it be accessible 
only to that user, it makes sense to make the value of the private key as secure as 
possible. Accordingly, the private key itself is not stored in the key ring. Rather, this 
key is encrypted using CAST-128 (or IDEA or 3DES). The procedure is as follows: 


1. The user selects a passphrase to be used for encrypting private keys. 


2. When the system generates a new public/private key pair using RSA, it asks 
the user for the passphrase. Using SHA-1, a 160-bit hash code is generated 
from the passphrase, and the passphrase is discarded. 


3. The system encrypts the private key using CAST-128 with the 128 bits of 
the hash code as the key. The hash code is then discarded, and the encrypted 
private key is stored in the private-key ring. 


Subsequently, when a user accesses the private-key ring to retrieve a pri- 
vate key, he or she must supply the passphrase. PGP will retrieve the encrypted 
private key, generate the hash code of the passphrase, and decrypt the encrypted 
private key using CAST-128 with the hash code. 

This is a very compact and effective scheme. As in any system based on pass- 
words, the security of this system depends on the security of the password. To avoid 
the temptation to write it down, the user should use a passphrase that is not easily 
guessed but that is easily remembered. 

Figure 18.4 also shows the general structure of a public-key ring. This data 
structure is used to store public keys of other users that are known to this user. For 
the moment, let us ignore some fields shown in the figure and describe the following 
fields. 


e Timestamp: The date/time when this entry was generated. 
e Key ID: The least significant 64 bits of the public key for this entry. 
e Public Key: The public key for this entry. 


e User ID: Identifies the owner of this key. Multiple user IDs may be associated 
with a single public key. 


The public-key ring can be indexed by either User ID or Key ID; we will see 
the need for both means of indexing later. 

We are now in a position to show how these key rings are used in message 
transmission and reception. For simplicity, we ignore compression and radix-64 con- 
version in the following discussion. First consider message transmission (Figure 18.5) 
and assume that the message is to be both signed and encrypted. The sending PGP 
entity performs the following steps. 


Private-key ring 


Passphrase 
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PGP Message Generation (from User A to User B: no compression or radix-64 


a. 


c. 


Signing the message: 


PGP retrieves the sender’s private key from the private-key ring using 
your_userid as an index. If your_userid was not provided in the 
command, the first private key on the ring is retrieved. 


. PGP prompts the user for the passphrase to recover the unencrypted private 


Key. 
The signature component of the message is constructed. 


. Encrypting the message: 


a. 


b. 


c. 


PGP generates a session key and encrypts the message. 


PGP retrieves the recipient’s public key from the public-key ring using 
her_userid as an index. 


The session key component of the message is constructed. 


The receiving PGP entity performs the following steps (Figure 18.6). 


a. 


Decrypting the message: 


PGP retrieves the receiver’s private key from the private-key ring using the 
Key ID field in the session key component of the message as an index. 


. PGP prompts the user for the passphrase to recover the unencrypted 


private key. 
PGP then recovers the session key and decrypts the message. 
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Figure 18.6 PGP Message Reception (from User A to User B; no compression or radix-64 
conversion) 


2. Authenticating the message: 


a. PGP retrieves the sender’s public key from the public-key ring using the Key 
ID field in the signature key component of the message as an index. 


b. PGP recovers the transmitted message digest. 


c. PGP computes the message digest for the received message and compares it 
to the transmitted message digest to authenticate. 


Public-Key Management 


As can be seen from the discussion so far, PGP contains a clever, efficient, interlock- 
ing set of functions and formats to provide an effective confidentiality and authenti- 
cation service. To complete the system, one final area needs to be addressed, that 
of public-key management. The PGP documentation captures the importance of 
this area: 


This whole business of protecting public keys from tampering is the 
single most difficult problem in practical public key applications. It 
is the “Achilles heel” of public key cryptography, and a lot of soft- 
ware complexity is tied up in solving this one problem. 
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PGP provides a structure for solving this problem with several suggested 
options that may be used. Because PGP is intended for use in a variety of formal 
and informal environments, no rigid public-key management scheme is set up, such 
as we will see in our discussion of S/MIME later in this chapter. 


APPROACHES TO PUBLIC-KEY MANAGEMENT The essence of the problem is this: User 
A must build up a public-key ring containing the public keys of other users to 
interoperate with them using PGP. Suppose that A’s key ring contains a public key 
attributed to B, but in fact the key is owned by C. This could happen, for example, if 
A got the key from a bulletin board system (BBS) that was used by B to post the 
public key but that has been compromised by C. The result is that two threats now 
exist. First, C can send messages to A and forge B’s signature so that A will accept 
the message as coming from B. Second, any encrypted message from A to B can be 
read by C. 

A number of approaches are possible for minimizing the risk that a user’s 
public-key ring contains false public keys. Suppose that A wishes to obtain a reliable 
public key for B. The following are some approaches that could be used. 


1. Physically get the key from B. B could store her public key (PU;) on a floppy 
disk and hand it to A. A could then load the key into his system from the 
floppy disk. This is a very secure method but has obvious practical limitations. 


nN 


. Verify a key by telephone. If A can recognize B on the phone, A could call B and 
ask her to dictate the key, in radix-64 format, over the phone. As a more practical 
alternative, B could transmit her key in an e-mail message to A. A could have 
PGP generate a 160-bit SHA-1 digest of the key and display it in hexadecimal 
format; this is referred to as the “fingerprint” of the key. A could then call B and 
ask her to dictate the fingerprint over the phone. If the two fingerprints match, 
the key is verified. 


3. Obtain B’s public key from a mutual trusted individual D. For this purpose, the 
introducer, D, creates a signed certificate. The certificate includes B’s public key, 
the time of creation of the key, and a validity period for the key. D generates an 
SHA-1 digest of this certificate, encrypts it with her private key, and attaches the 
signature to the certificate. Because only D could have created the signature, no 
one else can create a false public key and pretend that it is signed by D. The 
signed certificate could be sent directly to A by B or D, or it could be posted on a 
bulletin board. 


4. Obtain B’s public key from a trusted certifying authority. Again, a public-key 
certificate is created and signed by the authority. A could then access the 
authority, providing a user name and receiving a signed certificate. 


For cases 3 and 4, A already would have to have a copy of the introducer’s 
public key and trust that this key is valid. Ultimately, it is up to A to assign a level of 
trust to anyone who is to act as an introducer. 


THE Use or Trust Although PGP does not include any specification for establishing 
certifying authorities or for establishing trust, it does provide a convenient means of 
using trust, associating trust with public keys, and exploiting trust information. 
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The basic structure is as follows. Each entry in the public-key ring is a public- 
key certificate, as described in the preceding subsection. Associated with each such 
entry is a key legitimacy field that indicates the extent to which PGP will trust that 
this is a valid public key for this user; the higher the level of trust, the stronger is the 
binding of this user ID to this key. This field is computed by PGP. Also associated 
with the entry are zero or more signatures that the key ring owner has collected that 
sign this certificate. In turn, each signature has associated with it a signature trust 
field that indicates the degree to which this PGP user trusts the signer to certify pub- 
lic keys. The key legitimacy field is derived from the collection of signature trust 
fields in the entry. Finally, each entry defines a public key associated with a particu- 
lar owner, and an owner trust field is included that indicates the degree to which this 
public key is trusted to sign other public-key certificates; this level of trust is 
assigned by the user. We can think of the signature trust fields as cached copies of 
the owner trust field from another entry. 

The three fields mentioned in the previous paragraph are each contained in a 
structure referred to as a trust flag byte. The content of this trust flag for each of 
these three uses is shown in Table 18.2. Suppose that we are dealing with the public- 
key ring of user A. We can describe the operation of the trust processing as follows. 


1. When A inserts a new public key on the public-key ring, PGP must assign 
a value to the trust flag that is associated with the owner of this public key. If 
the owner is A, and therefore this public key also appears in the private-key 
ring, then a value of ultimate trust is automatically assigned to the trust field. 


Table 18.2 Contents of Trust Flag Byte 


(a) Trust Assigned to 
Public-Key Owner 
(appears after key packet; 
user defined) 


(b) Trust Assigned to Public 
Key/User ID Pair (appears after 
User ID packet; computed 

by PGP) 


(c) Trust Assigned to Signature 
(appears after signature packet; 
cached copy of OWNERTRUST 
for this signator) 


OWNERTRUST Field KEYLEGIT Field SIGTRUST Field 


—undefined trust 
—unknown user 


—usually not trusted to sign 
other keys 


—usually trusted to sign 
other keys 


—always trusted to sign 
other keys 

—this key is present in 
secret key ring 
(ultimate trust) 


—unknown or undefined trust 
—key ownership not trusted 
—marginal trust in key ownership 


—complete trust in key ownership 


—undefined trust 

—unknown user 

—usually not trusted to sign other 
keys 

—usually trusted to sign other keys 

—always trusted to sign other keys 


—this key is present in secret key 
ring (ultimate trust) 


BUCKSTOP bit 


—set if this key appears in 
secret key ring 


WARNONLY bit 


—set if user wants only to be 


warned when key that is not fully 


validated is used for encryption 


CONTIG bit 


—set if signature leads up a 
contiguous trusted certification 
path back to the ultimately 
trusted key ring owner 
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Otherwise, PGP asks A for his assessment of the trust to be assigned to the 
owner of this key, and A must enter the desired level. The user can specify 
that this owner is unknown, untrusted, marginally trusted, or completely 
trusted. 


Nn 


. When the new public key is entered, one or more signatures may be attached to 
it. More signatures may be added later. When a signature is inserted into the 
entry, PGP searches the public-key ring to see if the author of this signature is 
among the known public-key owners. If so, the OWNERTRUST value for this 
owner is assigned to the SIGTRUST field for this signature. If not, an unknown 
user value is assigned. 


3. The value of the key legitimacy field is calculated on the basis of the signature 
trust fields present in this entry. If at least one signature has a signature trust 
value of ultimate, then the key legitimacy value is set to complete. Otherwise, 
PGP computes a weighted sum of the trust values. A weight of 1/X is given to 
signatures that are always trusted and 1/Y to signatures that are usually 
trusted, where X and Y are user-configurable parameters. When the total of 
weights of the introducers of a Key/UserID combination reaches 1, the bind- 
ing is considered to be trustworthy, and the key legitimacy value is set to com- 
plete. Thus, in the absence of ultimate trust, at least X signatures that are 
always trusted, Y signatures that are usually trusted, or some combination is 
needed. 


Periodically, PGP processes the public-key ring to achieve consistency. In 
essence, this is a top-down process. For each OWNERTRUST field, PGP scans the 
ring for all signatures authored by that owner and updates the SIGTRUST field to 
equal the OWNERTRUST field. This process starts with keys for which there is ulti- 
mate trust. Then all KEYLEGIT fields are computed on the basis of the attached 
signatures. 

Figure 18.7 provides an example of the way in which signature trust and key 
legitimacy are related.* The figure shows the structure of a public-key ring. The user 
has acquired a number of public keys—some directly from their owners and some 
from a third party such as a key server. 

The node labeled “You” refers to the entry in the public-key ring correspond- 
ing to this user. This key is legitimate, and the OWNERTRUST value is ultimate 
trust. Each other node in the key ring has an OWNERTRUST value of undefined 
unless some other value is assigned by the user. In this example, this user has speci- 
fied that it always trusts the following users to sign other keys: D, E, FE, L. This user 
partially trusts users A and B to sign other keys. 

So the shading, or lack thereof, of the nodes in Figure 18.7 indicates the level 
of trust assigned by this user. The tree structure indicates which keys have been 
signed by which other users. If a key is signed by a user whose key is also in this key 
ring, the arrow joins the signed key to the signatory. If the key is signed by a user 
whose key is not present in this key ring, the arrow joins the signed key to a question 
mark, indicating that the signatory is unknown to this user. 


3Figure provided to the author by Phil Zimmermann. 
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9 = unknown signatory 


«--®) = X is signed by Y 


9 
: S ? 
O = key's owner is trusted by you to sign keys oa 


(S) = key's owner is partly trusted by you to sign keys 


@) = key is deemed legitimate by you 


Figure 18.7 PGP Trust Model Example 


n 


Several points are illustrated in Figure 18.7. 


Note that all keys whose owners are fully or partially trusted by this user have 
been signed by this user, with the exception of node L. Such a user signature is 
not always necessary, as the presence of node L indicates, but in practice, most 
users are likely to sign the keys for most owners that they trust. So, for exam- 
ple, even though E’s key is already signed by trusted introducer F, the user 
chose to sign E’s key directly. 

We assume that two partially trusted signatures are sufficient to certify a key. 


Hence, the key for user H is deemed legitimate by PGP because it is signed by A 
and B, both of whom are partially trusted. 


. A key may be determined to be legitimate because it is signed by one fully 


trusted or two partially trusted signatories, but its user may not be trusted to sign 
other keys. For example, N’s key is legitimate because it is signed by E, whom this 
user trusts, but N is not trusted to sign other keys because this user has not 
assigned N that trust value. Therefore, although R’s key is signed by N, PGP does 
not consider R’s key legitimate. This situation makes perfect sense. If you wish to 
send a private message to some individual, it is not necessary that you trust that 
individual in any respect. It is only necessary that you are sure that you have the 
correct public key for that individual. 


. Figure 18.7 also shows an example of a detached “orphan” node S, with two 


unknown signatures. Such a key may have been acquired from a key server. 
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PGP cannot assume that this key is legitimate simply because it came from a 
reputable server. The user must declare the key legitimate by signing it or by 
telling PGP that it is willing to trust fully one of the key’s signatories. 


A final point: Earlier it was mentioned that multiple user IDs may be associ- 
ated with a single public key on the public-key ring. This could be because a person 
has changed names or has been introduced via signature under multiple names, indi- 
cating different e-mail addresses for the same person, for example. So we can think of 
a public key as the root of a tree. A public key has a number of user IDs associating 
with it, with a number of signatures below each user ID. The binding of a particular 
user ID to a key depends on the signatures associated with that user ID and that key, 
whereas the level of trust in this key (for use in signing other keys) is a function of all 
the dependent signatures. 


REVOKING PuBLic Keys A user may wish to revoke his or her current public key 
either because compromise is suspected or simply to avoid the use of the same key for 
an extended period. Note that a compromise would require that an opponent 
somehow had obtained a copy of your unencrypted private key or that the opponent 
had obtained both the private key from your private-key ring and your passphrase. 

The convention for revoking a public key is for the owner to issue a key revo- 
cation certificate, signed by the owner. This certificate has the same form as a nor- 
mal signature certificate but includes an indicator that the purpose of this certificate 
is to revoke the use of this public key. Note that the corresponding private key must 
be used to sign a certificate that revokes a public key. The owner should then 
attempt to disseminate this certificate as widely and as quickly as possible to enable 
potential correspondents to update their public-key rings. 

Note that an opponent who has compromised the private key of an owner can 
also issue such a certificate. However, this would deny the opponent as well as the 
legitimate owner the use of the public key, and therefore, it seems a much less likely 
threat than the malicious use of a stolen private key. 


18.2 S/MIME 


Secure/Multipurpose Internet Mail Extension (S/MIME) is a security enhancement 
to the MIME Internet e-mail format standard based on technology from RSA Data 
Security. Although both PGP and S/MIME are on an IETF standards track, it 
appears likely that S/MIME will emerge as the industry standard for commercial and 
organizational use, while PGP will remain the choice for personal e-mail security for 
many users. S/MIME is defined in a number of documents—most importantly RFCs 
3370, 3850, 3851, and 3852. 

To understand S/MIME, we need first to have a general understanding of the 
underlying e-mail format that it uses, namely MIME. But to understand the signifi- 
cance of MIME, we need to go back to the traditional e-mail format standard, RFC 
822, which is still in common use. The most recent version of this format specifica- 
tion is RFC 5322 (Internet Message Format). Accordingly, this section first provides 
an introduction to these two earlier standards and then moves on to a discussion of 
S/MIME. 
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RFC 5322 


RFC 5322 defines a format for text messages that are sent using electronic mail. It has 
been the standard for Internet-based text mail messages and remains in common use. 
In the RFC 5322 context, messages are viewed as having an envelope and contents. The 
envelope contains whatever information is needed to accomplish transmission and 
delivery. The contents compose the object to be delivered to the recipient. The RFC 
5322 standard applies only to the contents. However, the content standard includes a 
set of header fields that may be used by the mail system to create the envelope, and the 
standard is intended to facilitate the acquisition of such information by programs. 

The overall structure of a message that conforms to RFC 5322 is very simple. 
A message consists of some number of header lines (the header) followed by unre- 
stricted text (the body). The header is separated from the body by a blank line. Put 
differently, a message is ASCII text, and all lines up to the first blank line are 
assumed to be header lines used by the user agent part of the mail system. 

A header line usually consists of a keyword, followed by a colon, followed by 
the keyword’s arguments; the format allows a long line to be broken up into several 
lines. The most frequently used keywords are From, To, Subject, and Date. Here is an 
example message: 


Date: October 8, 2009 2:15:49 PM EDT 
From: "William Stallings" <ws@shore.net> 
Subject: The Syntax in RFC 5322 

To: Smith@Other-host.com 

Cc: Jones@Yet-Another-Host.com 


Hello. This section begins the actual 
message body, which is delimited from the 


message heading by a blank line. 


Another field that is commonly found in RFC 5322 headers is Message-ID. 
This field contains a unique identifier associated with this message. 


Multipurpose Internet Mail Extensions 


Multipurpose Internet Mail Extension (MIME) is an extension to the RFC 5322 
framework that is intended to address some of the problems and limitations of the 
use of Simple Mail Transfer Protocol (SMTP), defined in RFC 821, or some other 
mail transfer protocol and RFC 5322 for electronic mail. [PARZ06] lists the follow- 
ing limitations of the SMTP/5322 scheme. 


1. SMTP cannot transmit executable files or other binary objects. A number of 
schemes are in use for converting binary files into a text form that can be used 
by SMTP mail systems, including the popular UNIX UUencode/UUdecode 
scheme. However, none of these is a standard or even a de facto standard. 


Nn 


SMTP cannot transmit text data that includes national language characters, 
because these are represented by 8-bit codes with values of 128 decimal or 
higher, and SMTP is limited to 7-bit ASCIL. 


mn 


6. 


18.2 / S/MIME 589 


. SMTP servers may reject mail message over a certain size. 
. SMTP gateways that translate between ASCII and the character code EBCDIC 


do not use a consistent set of mappings, resulting in translation problems. 


. SMTP gateways to X.400 electronic mail networks cannot handle nontextual 


data included in X.400 messages. 


Some SMTP implementations do not adhere completely to the SMTP standards 
defined in RFC 821. Common problems include: 


e Deletion, addition, or reordering of carriage return and linefeed 
e Truncating or wrapping lines longer than 76 characters 

e Removal of trailing white space (tab and space characters) 

e Padding of lines in a message to the same length 

e Conversion of tab characters into multiple space characters 


MIME is intended to resolve these problems in a manner that is compatible 


with existing RFC 5322 implementations. The specification is provided in RFCs 
2045 through 2049. 


Overview The MIME specification includes the following elements. 


1. 


N 


Five new message header fields are defined, which may be included in an RFC 
5322 header. These fields provide information about the body of the message. 


. A number of content formats are defined, thus standardizing representations 


that support multimedia electronic mail. 


. Transfer encodings are defined that enable the conversion of any content for- 


mat into a form that is protected from alteration by the mail system. 


In this subsection, we introduce the five message header fields. The next two 


subsections deal with content formats and transfer encodings. 


The five header fields defined in MIME are 
MIME-Version: Must have the parameter value 1.0. This field indicates that 
the message conforms to RFCs 2045 and 2046. 


Content-Type: Describes the data contained in the body with sufficient detail 
that the receiving user agent can pick an appropriate agent or mechanism to 
represent the data to the user or otherwise deal with the data in an appropri- 
ate manner. 


Content-Transfer-Encoding: Indicates the type of transformation that has 
been used to represent the body of the message in a way that is acceptable for 
mail transport. 


Content-ID: Used to identify MIME entities uniquely in multiple contexts. 


Content-Description: A text description of the object with the body; this is 
useful when the object is not readable (e.g., audio data). 


Any or all of these fields may appear in a normal RFC 5322 header. A compliant 


implementation must support the MIME-Version, Content-Type, and Content- 
Transfer-Encoding fields; the Content-ID and Content-Description fields are optional 
and may be ignored by the recipient implementation. 
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MIME Content Types The bulk of the MIME specification is concerned with the 
definition of a variety of content types. This reflects the need to provide 
standardized ways of dealing with a wide variety of information representations in a 
multimedia environment. 

Table 18.3 lists the content types specified in RFC 2046. There are seven different 
major types of content and a total of 15 subtypes. In general, a content type declares the 
general type of data, and the subtype specifies a particular format for that type of data. 

For the text type of body, no special software is required to get the full meaning 
of the text aside from support of the indicated character set. The primary subtype is 
plain text, which is simply a string of ASCII characters or ISO 8859 characters. The 
enriched subtype allows greater formatting flexibility. 

The multipart type indicates that the body contains multiple, independent 
parts. The Content-Type header field includes a parameter (called a boundary) that 
defines the delimiter between body parts. This boundary should not appear in any 
parts of the message. Each boundary starts on a new line and consists of two 
hyphens followed by the boundary value. The final boundary, which indicates the 
end of the last part, also has a suffix of two hyphens. Within each part, there may be 
an optional ordinary MIME header. 


Table 18.3. MIME Content Types 


Subtype Description 


Plain Unformatted text; may be ASCII or ISO 8859. 


Enriched Provides greater format flexibility. 


Multipart Mixed The different parts are independent but are to be transmitted together. They 
should be presented to the receiver in the order that they appear in the mail 
message. 


Parallel Differs from Mixed only in that no order is defined for delivering the parts to 
the receiver. 


Alternative The different parts are alternative versions of the same information. They are 
ordered in increasing faithfulness to the original, and the recipient’s mail 
system should display the “best” version to the user. 


Digest Similar to Mixed, but the default type/subtype of each part is message/rfc822. 


Message rfc822 The body is itself an encapsulated message that conforms to RFC 822. 


Partial Used to allow fragmentation of large mail items, in a way that is transparent 
to the recipient. 


External-body | Contains a pointer to an object that exists elsewhere. 


jpeg The image is in JPEG format, JFIF encoding. 


gif The image is in GIF format. 


Video mpeg MPEG format. 


Audio Basic Single-channel 8-bit ISDN mu-law encoding at a sample rate of 8 kHz. 


Application | PostScript Adobe Postscript format. 


octet-stream General binary data consisting of 8-bit bytes. 
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Here is a simple example of a multipart message containing two parts—both 


consisting of simple text (taken from RFC 2046). 


From: Nathaniel Borenstein <nsb@bellcore.com> 


To: Ned Freed <ned@innosoft.com> 
Subject: Sample message 
MIME-Version: 1.0 


Content-type: multipart/mixed; boundary="simple 


boundary" 


This is the preamble. It is to be ignored, 


is a handy place for mail composers to 


explanatory note to non-MIME conformant readers. 


—simple boundary 


This is implicitly typed plain ASC text. 


end with a linebreak. 
—simple boundary 
Content-type: text/plain; charset=us-ascii 


though it 


include an 


It does NOT 


This is explicitly typed plain ASC text. t DOES end 
with a linebreak. 

—simple boundary— 

This is the epilogue. It is also to be ignored. 


There are four subtypes of the multipart type, all of which have the same over- 
all syntax. The multipart/mixed subtype is used when there are multiple indepen- 
dent body parts that need to be bundled in a particular order. For the 
multipart/parallel subtype, the order of the parts is not significant. If the recipient’s 
system is appropriate, the multiple parts can be presented in parallel. For example, a 
picture or text part could be accompanied by a voice commentary that is played 


while the picture or text is displayed. 


For the multipart/alternative subtype, the various parts are different represen- 


tations of the same information. The following is an example: 


From: Nathaniel Borenstein <nsb@bellcore.com> 


To: Ned Freed <ned@innosoft.com> 
Subject: Formatted text mail 
MIME-Version: 1.0 

Content-Type: multipart/alternative; 
boundary=boundary42 


—boundary42 


Content-Type: text/plain; charset=us-ascii 


...plain text version of message goes here.... 
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—boundary42 
Content-Type: text/enriched 


RFC 1896 text/enriched version of same message 
goes here 


—boundary42— 


In this subtype, the body parts are ordered in terms of increasing preference. 
For this example, if the recipient system is capable of displaying the message in the 
text/enriched format, this is done; otherwise, the plain text format is used. 

The multipart/digest subtype is used when each of the body parts is inter- 
preted as an RFC 5322 message with headers. This subtype enables the construction 
of a message whose parts are individual messages. For example, the moderator of a 
group might collect e-mail messages from participants, bundle these messages, and 
send them out in one encapsulating MIME message. 

The message type provides a number of important capabilities in MIME. The 
message/rfc822 subtype indicates that the body is an entire message, including 
header and body. Despite the name of this subtype, the encapsulated message may 
be not only a simple RFC 5322 message but also any MIME message. 

The message/partial subtype enables fragmentation of a large message into a 
number of parts, which must be reassembled at the destination. For this subtype, 
three parameters are specified in the Content-Type: Message/Partial field: an id 
common to all fragments of the same message, a sequence number unique to each 
fragment, and the total number of fragments. 

The message/external-body subtype indicates that the actual data to be con- 
veyed in this message are not contained in the body. Instead, the body contains the 
information needed to access the data. As with the other message types, the mes- 
sage/external-body subtype has an outer header and an encapsulated message with 
its own header. The only necessary field in the outer header is the Content-Type 
field, which identifies this as a message/external-body subtype. The inner header is 
the message header for the encapsulated message. The Content-Type field in the 
outer header must include an access-type parameter, which indicates the method of 
access, such as FTP (file transfer protocol). 

The application type refers to other kinds of data, typically either uninter- 
preted binary data or information to be processed by a mail-based application. 


MIME TRANSFER ENncopincs The other major component of the MIME 
specification, in addition to content type specification, is a definition of transfer 
encodings for message bodies. The objective is to provide reliable delivery across 
the largest range of environments. 

The MIME standard defines two methods of encoding data. The Content- 
Transfer-Encoding field can actually take on six values, as listed in Table 18.4. 
However, three of these values (7bit, 8bit, and binary) indicate that no encoding has 
been done but provide some information about the nature of the data. For SMTP 
transfer, it is safe to use the 7bit form. The 8bit and binary forms may be usable in 
other mail transport contexts. Another Content-Transfer-Encoding value is x-token, 


18.2 / S/MIME 593 


Table 18.4 MIME Transfer Encodings 


Tbit The data are all represented by short lines of ASCII characters. 


S8bit The lines are short, but there may be non-ASCII characters (octets with the 
high-order bit set). 


binary Not only may non-ASCII characters be present, but the lines are not necessar- 
ily short enough for SMTP transport. 


quoted-printable | Encodes the data in such a way that if the data being encoded are mostly 
ASCII text, the encoded form of the data remains largely recognizable by 
humans. 


base64 Encodes data by mapping 6-bit blocks of input to 8-bit blocks of output, all of 
which are printable ASCII characters. 


x-token A named nonstandard encoding. 


which indicates that some other encoding scheme is used for which a name is to be 
supplied. This could be a vendor-specific or application-specific scheme. The two 
actual encoding schemes defined are quoted-printable and base64. Two schemes are 
defined to provide a choice between a transfer technique that is essentially human 
readable and one that is safe for all types of data in a way that is reasonably compact. 

The quoted-printable transfer encoding is useful when the data consists 
largely of octets that correspond to printable ASCII characters. In essence, it 
represents nonsafe characters by the hexadecimal representation of their code and 
introduces reversible (soft) line breaks to limit message lines to 76 characters. 

The base64 transfer encoding, also known as radix-64 encoding, is a common 
one for encoding arbitrary binary data in such a way as to be invulnerable to the 
processing by mail-transport programs. It is also used in PGP and is described in 
Appendix 18A. 


A Mouvtipart ExAmpLe Figure 18.8, taken from RFC 2045, is the outline of a 
complex multipart message. The message has five parts to be displayed serially: two 
introductory plain text parts, an embedded multipart message, a richtext part, and a 
closing encapsulated text message in a non-ASCII character set. The embedded 
multipart message has two parts to be displayed in parallel: a picture and an audio 
fragment. 


CANONICAL Form An important concept in MIME and S/MIME is that of 
canonical form. Canonical form is a format, appropriate to the content type, that is 
standardized for use between systems. This is in contrast to native form, which is a 
format that may be peculiar to a particular system. Table 18.5, from RFC 2049, 
should help clarify this matter. 


S/MIME Functionality 


In terms of general functionality, S/MIME is very similar to PGP. Both offer the 
ability to sign and/or encrypt messages. In this subsection, we briefly summarize 
S/MIME capability. We then look in more detail at this capability by examining mes- 
sage formats and message preparation. 
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MIME-Version: 1.0 

From: Nathaniel Borenstein <nsb @bellcore.com> 

To: Ned Freed <ned @innosoft.com> 

Subject: A multipart example 

Content-Type: multipart/mixed; 
boundary=unique-boundary-! 


This is the preamble area of a multipart message. Mail readers that understand multipart format should ignore 
this preamble. If you are reading this text, you might want to consider changing to a mail reader that understands 
how to properly display multipart messages. 


--unique-boundary-1 


...5ome text appears here... 
[Note that the preceding blank line means no header fields were given and this is text, with charset US ASCIL. 
It could have been done with explicit typing as in the next part.] 


--unique-boundary- 1 
Content-type: text/plain; charset=US-ASCII 


This could have been part of the previous part, but illustrates explicit versus implicit typing of body parts. 


--unique-boundary- 1 
Content-Type: multipart/parallel; boundary=unique-boundary-2 


--unique-boundary-2 
Content-Type: audio/basic 
Content-Transfer-Encoding: base64 


... base64-encoded 8000 Hz single-channel mu-law-format audio data goes here.... 


--unique-boundary-2 
Content-Type: image/jpeg 
Content-Transfer-Encoding: base64 


... base64-encoded image data goes here.... 
--unique-boundary-2-- 


--unique-boundary- 1 
Content-type: text/enriched 


This is <bold><italic>richtext.</italic></bold> <smaller>as defined in RFC 1896</smaller> 
Isn't it <bigger><bigger>cool?</bigger></bigger> 


--unique-boundary- 1 
Content-Type: message/rfc822 


From: (mailbox in US-ASCID 

To: (address in US-ASCII) 

Subject: (subject in US-ASCID 

Content-Type: Text/plain; charset=ISO-8859-1 
Content-Transfer-Encoding: Quoted-printable 


... Additional text in ISO-8859-1 goes here ... 


--unique-boundary- | -- 


Figure 18.8 Example MIME Message Structure 
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Table 18.5 Native and Canonical Form 


The body to be transmitted is created in the system’s native format. The native char- 
acter set is used and, where appropriate, local end-of-line conventions are used as 
well. The body may be a UNIX-style text file, or a Sun raster image, or a VMS 
indexed file, or audio data in a system-dependent format stored only in memory, or 
anything else that corresponds to the local model for the representation of some 
form of information. Fundamentally, the data is created in the “native” form that 
corresponds to the type specified by the media type. 


Canonical The entire body, including “out-of-band” information such as record lengths and pos- 
Form sibly file attribute information, is converted to a universal canonical form. The spe- 
cific media type of the body as well as its associated attributes dictate the nature of 
the canonical form that is used. Conversion to the proper canonical form may 
involve character set conversion, transformation of audio data, compression, or vari- 
ous other operations specific to the various media types. If character set conversion 
is involved, however, care must be taken to understand the semantics of the media 
type, which may have strong implications for any character set conversion (e.g., with 
regard to syntactically meaningful characters in a text subtype other than “plain”). 


Functions S/MIME provides the following functions. 


e Enveloped data: This consists of encrypted content of any type and encrypted- 
content encryption keys for one or more recipients. 


e Signed data: A digital signature is formed by taking the message digest of the 
content to be signed and then encrypting that with the private key of the signer. 
The content plus signature are then encoded using base64 encoding. A signed 
data message can only be viewed by a recipient with S/MIME capability. 


e Clear-signed data: As with signed data, a digital signature of the content is 
formed. However, in this case, only the digital signature is encoded using 
base64. As a result, recipients without S/MIME capability can view the message 
content, although they cannot verify the signature. 


e Signed and enveloped data: Signed-only and encrypted-only entities may be 
nested, so that encrypted data may be signed and signed data or clear-signed 
data may be encrypted. 


CRYPTOGRAPHIC ALGORITHMS Table 18.6 summarizes the cryptographic algorithms 
used in S/MIME. S/MIME uses the following terminology taken from RFC 2119 (Key 
Words for use in RFCs to Indicate Requirement Levels) to specify the requirement level: 


e MUST: The definition is an absolute requirement of the specification. An 
implementation must include this feature or function to be in conformance 
with the specification. 


e SHOULD: There may exist valid reasons in particular circumstances to ignore 
this feature or function, but it is recommended that an implementation include 
the feature or function. 


S/MIME incorporates three public-key algorithms. The Digital Signature 
Standard (DSS) described in Chapter 13 is the preferred algorithm for digital 
signature. S/MIME lists Diffie-Hellman as the preferred algorithm for encrypting 
session keys; in fact, S/MIME uses a variant of Diffie-Hellman that does provide 
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Table 18.6 Cryptographic Algorithms Used in S/MIME 


Function Requirement 


Create a message digest to be used in MUST support SHA-1. 
forming a digital signature. Receiver SHOULD support MDS for backward compatibility. 


Encrypt message digest to form a digital Sending and receiving agents MUST support DSS. 
signature. Sending agents SHOULD support RSA encryption. 


Receiving agents SHOULD support verification of RSA 
signatures with key sizes 512 bits to 1024 bits. 


Encrypt session key for transmission with | Sending and receiving agents SHOULD support Diffie-Hellman. 


EE eee ocr Sending and receiving agents MUST support RSA encryption 
with key sizes 512 bits to 1024 bits. 


Encrypt message for transmission with a Sending and receiving agents MUST support encryption with 
one-time session key. tripleDES. 


Sending agents SHOULD support encryption with AES. 
Sending agents SHOULD support encryption with RC2/40. 


Create a message authentication code. Receiving agents MUST support HMAC with SHA-1. 
Sending agents SHOULD support HMAC with SHA-1. 


encryption/decryption, known as ElGamal (Chapter 10). As an alternative, RSA, 
described in Chapter 9, can be used for both signatures and session key encryption. 
These are the same algorithms used in PGP and provide a high level of security. For 
the hash function used to create the digital signature, the specification requires the 
160-bit SHA-1 but recommends receiver support for the 128-bit MD5 for backward 
compatibility with older versions of S/MIME. As we discussed in Chapter 11, there 
is justifiable concern about the security of MD5, so SHA-1 is clearly the preferred 
alternative. 

For message encryption, three-key triple DES (tripleDES) is recommended, 
but compliant implementations must support 40-bit RC2. The latter is a weak 
encryption algorithm but allows compliance with U.S. export controls. 

The S/MIME specification includes a discussion of the procedure for deciding 
which content encryption algorithm to use. In essence, a sending agent has two deci- 
sions to make. First, the sending agent must determine if the receiving agent is capa- 
ble of decrypting using a given encryption algorithm. Second, if the receiving agent 
is only capable of accepting weakly encrypted content, the sending agent must 
decide if it is acceptable to send using weak encryption. To support this decision 
process, a sending agent may announce its decrypting capabilities in order of prefer- 
ence for any message that it sends out. A receiving agent may store that information 
for future use. 

The following rules, in the following order, should be followed by a sending 
agent. 


1. If the sending agent has a list of preferred decrypting capabilities from an 
intended recipient, it SHOULD choose the first (highest preference) capabil- 
ity on the list that it is capable of using. 
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nN 


. If the sending agent has no such list of capabilities from an intended recipient but 
has received one or more messages from the recipient, then the outgoing mes- 
sage SHOULD use the same encryption algorithm as was used on the last signed 
and encrypted message received from that intended recipient. 


7) 


. If the sending agent has no knowledge about the decryption capabilities of the 
intended recipient and is willing to risk that the recipient may not be able to 
decrypt the message, then the sending agent SHOULD use triple DES. 


4. If the sending agent has no knowledge about the decryption capabilities of the 
intended recipient and is not willing to risk that the recipient may not be able 
to decrypt the message, then the sending agent MUST use RC2/40. 


If a message is to be sent to multiple recipients and a common encryption 
algorithm cannot be selected for all, then the sending agent will need to send two 
messages. However, in that case, it is important to note that the security of the mes- 
sage is made vulnerable by the transmission of one copy with lower security. 


S/MIME Messages 


S/MIME makes use of a number of new MIME content types, which are shown in 
Table 18.7. All of the new application types use the designation PKCS. This refers to 
a set of public-key cryptography specifications issued by RSA Laboratories and 
made available for the S/MIME effort. 

We examine each of these in turn after first looking at the general procedures 
for S/MIME message preparation. 


SECURING A MIME EnvTity S/MIME secures a MIME entity with a signature, 
encryption, or both. A MIME entity may be an entire message (except for the 
RFC 5322 headers), or if the MIME content type is multipart, then a MIME entity is 
one or more of the subparts of the message. The MIME entity is prepared according 
to the normal rules for MIME message preparation. Then the MIME entity plus 
some security-related data, such as algorithm identifiers and certificates, are 
processed by S/MIME to produce what is known as a PKCS object. A PKCS object 
is then treated as message content and wrapped in MIME (provided with 
appropriate MIME headers). This process should become clear as we look at 
specific objects and provide examples. 

In all cases, the message to be sent is converted to canonical form. In particu- 
lar, for a given type and subtype, the appropriate canonical form is used for the mes- 
sage content. For a multipart message, the appropriate canonical form is used for 
each subpart. 

The use of transfer encoding requires special attention. For most cases, the result 
of applying the security algorithm will be to produce an object that is partially or totally 
represented in arbitrary binary data. This will then be wrapped in an outer MIME 
message, and transfer encoding can be applied at that point, typically base64. However, 
in the case of a multipart signed message (described in more detail later), the message 
content in one of the subparts is unchanged by the security process. Unless that content 
is 7bit, it should be transfer encoded using base64 or quoted-printable so that there is 
no danger of altering the content to which the signature was applied. 

We now look at each of the S/MIME content types. 
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Table 18.7 S/MIME Content Types 


Type 


Subtype smime Parameter Description 


Multipart 


Signed 


A clear-signed message in two parts: one is the 
message and the other is the signature. 


Application 


pkcs7-mime signedData A signed S/MIME entity. 


pkcs7-mime env 


elopedData An encrypted S/MIME entity. 


pkcs7-mime deg! 


signedData 


enerate An entity containing only public-key certificates. 


pkcs7-mime CompressedData | A compressed S/MIME entity. 


pkces7- signedData The content type of the signature subpart of a 


signature 


multipart/signed message. 


ENVELOPEDDaTA An application/pkcs7-mime subtype is used for one of four 
categories of S/MIME processing, each with a unique smime-type parameter. In all 
cases, the resulting entity (referred to as an object) is represented in a form known 
as Basic Encoding Rules (BER), which is defined in ITU-T Recommendation 
X.209. The BER format consists of arbitrary octet strings and is therefore binary 
data. Such an object should be transfer encoded with base64 in the outer MIME 
message. We first look at envelopedData. 


The steps for prep 


1. Generate a pse 


aring an envelopedData MIME entity are 


udorandom session key for a particular symmetric encryp- 


tion algorithm (RC2/40 or triple DES). 
2. For each recipient, encrypt the session key with the recipient’s public RSA key. 


3. For each recipie 


nt, prepare a block known as Recipient Info that contains 


an identifier of the recipient’s public-key certificate,* an identifier of the algo- 
rithm used to encrypt the session key, and the encrypted session key. 


4. Encrypt the me 


The Recipient] 


the envelopedData. 
message (excluding the RFC 5322 headers) is 


Content-Type: 


ssage content with the session key. 


[nfo blocks followed by the encrypted content constitute 
This information is then encoded into base64. A sample 


application/pkcs7-mime; smime-type=enveloped- 
data; name=smime.p7m 


Content-Transfer-Encoding: base64 


Content-Dispositi 


rfvbnj756tbi 


on: attachment; filename=smime.p7m 


BghyHhHUuj hJhjH7 7n8HHGTIHG4VOpfyF467GhIG£HEYT6 


7n8HHGghyHhHuUuj hJh4VOpfyF467GhIGfHFYGTrfvbnjT6jH7756tbB9IH 
f8HHGTr fvhJhjH776tbB9IHG4VObnj 7567GhHIGFHEYT6ghyHhHUujpfyF4 


0GhI 


[GEH£Qbnj756YT 


64V 


“This is an X.509 certificate, discussed later in this section. 
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To recover the encrypted message, the recipient first strips off the base64 
encoding. Then the recipient’s private key is used to recover the session key. Finally, 
the message content is decrypted with the session key. 


SIGNEDDATA The signedData smime-type can be used with one or more signers. 
For clarity, we confine our description to the case of a single digital signature. The 
steps for preparing a signedData MIME entity are 


1. Select a message digest algorithm (SHA or MDS). 

2. Compute the message digest (hash function) of the content to be signed. 
3. Encrypt the message digest with the signer’s private key. 
4 


. Prepare a block known as SignerInfo that contains the signer’s public- 
key certificate, an identifier of the message digest algorithm, an identifier of 
the algorithm used to encrypt the message digest, and the encrypted mes- 
sage digest. 


The signedData entity consists of a series of blocks, including a message 
digest algorithm identifier, the message being signed, and SignerInfo. The 
signedData entity may also include a set of public-key certificates sufficient to 
constitute a chain from a recognized root or top-level certification authority to the 
signer. This information is then encoded into base64. A sample message (excluding 
the RFC 5322 headers) is 


Content-Type: application/pkcs7-mime; smime-type=signed- 
data; name=smime.p7m 

Content-Transfer-Encoding: base64 

Content-Disposition: attachment; filename=smime.p7m 


567GhIG£HEYT6ghyHhHUujpfyF4 f 8HHGTr fvhJhj H77 6tbBIHG4VObnj 7 
7 7N8HHGTIHG4VOpfyF467GhHIGFHEYTb6rfvbnj756tbBghyHhHUujhdhjH 
HUujhdh4VOpfyF467GhIGfHEYGTrfvbnjT6jH7756tbBIH7n8HHGghyHh 
6YT64VOGhHIG£FHFQbnj75 


To recover the signed message and verify the signature, the recipient first 
strips off the base64 encoding. Then the signer’s public key is used to decrypt the 
message digest. The recipient independently computes the message digest and com- 
pares it to the decrypted message digest to verify the signature. 


CLEAR SIGNING Clear signing is achieved using the multipart content type with a 
signed subtype. As was mentioned, this signing process does not involve 
transforming the message to be signed, so that the message is sent “in the clear.” 
Thus, recipients with MIME capability but not S/MIME capability are able to read 
the incoming message. 

A multipart/signed message has two parts. The first part can be any MIME 
type but must be prepared so that it will not be altered during transfer from source 
to destination. This means that if the first part is not 7bit, then it needs to be encoded 


600 CHAPTER 18 / ELECTRONIC MAIL SECURITY 


using base64 or quoted-printable. Then this part is processed in the same manner as 
signedData, but in this case an object with signedData format is created that 
has an empty message content field. This object is a detached signature. It is then 
transfer encoded using base64 to become the second part of the multipart/signed 
message. This second part has a MIME content type of application and a subtype of 
pkcs7-signature. Here is a sample message: 


Content-Type: multipart/signed; 
protocol="application/pkcs7-signature"; 
micalg=shal; boundary=boundary42 


—boundary42 
Content-Type: text/plain 


This is a clear-signed message. 


—boundary42 
Content-Type: application/pkcs7-signature; name=smime.p7s 
Content-Transfer-Encoding: base64 


Content-Disposition: attachment; filename=smime.p7s 


ghyHhHUuj hJhjH77n8HHGTr fvbnj 756tbBIHG4VOpfyF467GhHIG£HEFYT6 
4VOpfyF467GhIGfHEYT6jH7 7n8HHGghyHhHUuj hdh756tbB9HGTrfvbnj 
n8HHGTr fvhJhjH776tbB9IHG4VObnj 7567GhHIGFHEYT6ghyHhHUujpfyF4 
7TGhIG£HEYT64VObnj 756 

—boundary42— 


The protocol parameter indicates that this is a two-part clear-signed entity. 
The micalg parameter indicates the type of message digest used. The receiver can 
verify the signature by taking the message digest of the first part and comparing this 
to the message digest recovered from the signature in the second part. 


REGISTRATION REQUEST Typically, an application or user will apply to a certification 
authority for a public-key certificate. The application/pkcs10 S/MIME entity is used to 
transfer a certification request. The certification request includes certification 
RequestInfo block, followed by an identifier of the public-key encryption 
algorithm, followed by the signature of the certificationRequest Info block 
made using the sender’s private key. The certificationRequestiInfo block 
includes a name of the certificate subject (the entity whose public key is to be 
certified) and a bit-string representation of the user’s public key. 


CERTIFICATES-ONLY MeEssAGE A message containing only certificates or a certificate 
revocation list (CRL) can be sent in response to a registration request. The message 
is an application/pkcs7-mime type/subtype with an smime-type parameter of 
degenerate. The steps involved are the same as those for creating a signedData 
message, except that there is no message content and the signerInfo field 
is empty. 
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S/MIME Certificate Processing 


S/MIME uses public-key certificates that conform to version 3 of X.509 
(see Chapter 14). The key-management scheme used by S/MIME is in some ways a 
hybrid between a strict X.509 certification hierarchy and PGP’s web of trust. 
As with the PGP model, S/MIME managers and/or users must configure each client 
with a list of trusted keys and with certificate revocation lists. That is, the responsi- 
bility is local for maintaining the certificates needed to verify incoming signatures 
and to encrypt outgoing messages. On the other hand, the certificates are signed by 
certification authorities. 


UsER AGENT Rote An S/MIME user has several key-management functions to 
perform. 


e Key generation: The user of some related administrative utility (e.g., one asso- 
ciated with LAN management) MUST be capable of generating separate 
Diffie-Hellman and DSS key pairs and SHOULD be capable of generating 
RSA key pairs. Each key pair MUST be generated from a good source of non- 
deterministic random input and be protected in a secure fashion. A user agent 
SHOULD generate RSA key pairs with a length in the range of 768 to 1024 bits 
and MUST NOT generate a length of less than 512 bits. 


Registration: A user’s public key must be registered with a certification 
authority in order to receive an X.509 public-key certificate. 


Certificate storage and retrieval: A user requires access to a local list of certifi- 
cates in order to verify incoming signatures and to encrypt outgoing messages. 
Such a list could be maintained by the user or by some local administrative 
entity on behalf of a number of users. 


VERISIGN CERTIFICATES There are several companies that provide certification authority 
(CA) services. For example, Nortel has designed an enterprise CA solution and can 
provide S/MIME support within an organization. There are a number of Internet-based 
CAs, including VeriSign, GTE, and the U.S. Postal Service. Of these, the most widely 
used is the VeriSign CA service, a brief description of which we now provide. 

VeriSign provides a CA service that is intended to be compatible with S/MIME 
and a variety of other applications. VeriSign issues X.509 certificates with the product 
name VeriSign Digital ID. As of early 1998, over 35,000 commercial Web sites were 
using VeriSign Server Digital IDs, and over a million consumer Digital IDs had been 
issued to users of Netscape and Microsoft browsers. 

The information contained in a Digital ID depends on the type of Digital ID 
and its use. At a minimum, each Digital ID contains 


e Owner’s public key 

e Owner’s name or alias 

e Expiration date of the Digital ID 

e Serial number of the Digital ID 

e Name of the certification authority that issued the Digital ID 

e Digital signature of the certification authority that issued the Digital ID 
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Digital IDs can also contain other user-supplied information, including 


e Address 
e E-mail address 


e Basic registration information (country, zip code, age, and gender) 


VeriSign provides three levels, or classes, of security for public-key certificates, 
as summarized in Table 18.8. A user requests a certificate online at VeriSign’s Web 
site or other participating Web sites. Class 1 and Class 2 requests are processed 
on line, and in most cases take only a few seconds to approve. Briefly, the following 
procedures are used. 


e For Class 1 Digital IDs, VeriSign confirms the user’s e-mail address by sending 
a PIN and Digital ID pick-up information to the e-mail address provided in 
the application. 


e For Class 2 Digital IDs, VeriSign verifies the information in the application 
through an automated comparison with a consumer database in addition to 


Table 18.8 Verisign Public-Key Certificate Classes 


Summary of 
Confirmation 
of Identity 


Class 1 


Class 2 


Class 3 


Automated unam- 
biguous name and 
e-mail address search. 


Same as Class 1, plus 
automated enrollment infor- 
mation check and automated 
address check. 


Same as Class 1, plus personal 
presence and ID documents 
plus Class 2 automated ID 
check for individuals; business 
records (or filings) for 
organizations. 


IA Private Key 
Protection 


PCA: trustworthy 
hardware; CA: trust- 
worthy software or 
trustworthy hardware. 


PCA and CA: trustworthy 
hardware. 


PCA and CA: trustworthy 
hardware. 


Certificate 
Applicant and 
Subscriber 
Private Key 
Protection 


Encryption software 
(PIN protected) 
recommended but not 
required. 


Encryption software (PIN 
protected) required. 


Encryption software (PIN 
protected) required; hardware 
token recommended but not 
required. 


Applications 
Implemented or 
Contemplated 
by Users 


Web-browsing and 
certain e-mail usage. 


IA = Issuing Authority 
CA — = Certification Authority 


PCA 


PIN = Personal Identification Number 
LRAA = Local Registration Authority Administrator 


Individual and intra- and 
inter-company e-mail, online 
subscriptions, password 
replacement, and software 
validation. 


= VeriSign public primary certification authority 


E-banking, corp. database 
access, personal banking, 
membership-based online 
services, content integrity 
services, e-commerce server, 
software validation; authenti- 
cation of LRAAs; and strong 
encryption for certain servers. 
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performing all of the checking associated with a Class 1 Digital ID. Finally, 
confirmation is sent to the specified postal address alerting the user that a 
Digital ID has been issued in his or her name. 


e For Class 3 Digital IDs, VeriSign requires a higher level of identity assurance. 
An individual must prove his or her identity by providing notarized creden- 
tials or applying in person. 


Enhanced Security Services 


As of this writing, three enhanced security services have been proposed in an 
Internet draft. The details of these may change, and additional services may be 
added. The three services are 


e Signed receipts: A signed receipt may be requested in a SignedData object. 
Returning a signed receipt provides proof of delivery to the originator of a 
message and allows the originator to demonstrate to a third party that the 
recipient received the message. In essence, the recipient signs the entire origi- 
nal message plus the original (sender’s) signature and appends the new signa- 
ture to form a new S/MIME message. 


Security labels: A security label may be included in the authenticated attrib- 
utes of a SignedData object. A security label is a set of security information 
regarding the sensitivity of the content that is protected by S/MIME encapsu- 
lation. The labels may be used for access control, by indicating which users are 
permitted access to an object. Other uses include priority (secret, confidential, 
restricted, and so on) or role based, describing which kind of people can see 
the information (e.g., patient’s health-care team, medical billing agents, etc.). 


e Secure mailing lists: When a user sends a message to multiple recipients, a cer- 
tain amount of per-recipient processing is required, including the use of each 
recipient’s public key. The user can be relieved of this work by employing the 
services of an S/MIME Mail List Agent (MLA). An MLA can take a single 
incoming message, perform the recipient-specific encryption for each recipi- 
ent, and forward the message. The originator of a message need only send the 
message to the MLA with encryption performed using the MLA’s public key. 


18.3 DOMAINKEYS IDENTIFIED MAIL 


DomainKeys Identified Mail (DKIM) is a specification for cryptographically signing 
e-mail messages, permitting a signing domain to claim responsibility for a message in 
the mail stream. Message recipients (or agents acting in their behalf) can verify the 
signature by querying the signer’s domain directly to retrieve the appropriate public 
key and thereby can confirm that the message was attested to by a party in posses- 
sion of the private key for the signing domain. DKIM is a proposed Internet 
Standard (RFC 4871: DomainKeys Identified Mail (DKIM) Signatures). DKIM has 
been widely adopted by a range of e-mail providers, including corporations, govern- 
ment agencies, gmail, yahoo, and many Internet Service Providers (ISPs). 
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This section provides an overview of DKIM. Before beginning our discussion 
of DKIM, we introduce the standard Internet mail architecture. Then we look at the 
threat that DKIM is intended to address, and finally provide an overview of DKIM 
operation. 


Internet Mail Architecture 


To understand the operation of DKIM, it is useful to have a basic grasp of the 
Internet mail architecture, which is currently defined in [CROCO09]. This subsection 
provides an overview of the basic concepts. 

At its most fundamental level, the Internet mail architecture consists of a user 
world in the form of Message User Agents (MUA), and the transfer world, in the 
form of the Message Handling Service (MHS), which is composed of Message 
Transfer Agents (MTA). The MHS accepts a message from one user and delivers it 
to one or more other users, creating a virtual MUA-to-MUA exchange environ- 
ment. This architecture involves three types of interoperability. One is directly 
between users: messages must be formatted by the MUA on behalf of the message 
author so that the message can be displayed to the message recipient by the destina- 
tion MUA. There are also interoperability requirements between the MUA and the 
MHS—rfirst when a message is posted from an MUA to the MHS and later when it 
is delivered from the MHS to the destination MUA. Interoperability is required 
among the MTA components along the transfer path through the MHS. 

Figure 18.9 illustrates the key components of the Internet mail architecture, 
which include the following. 


e Message User Agent (MUA): Works on behalf of user actors and user applica- 
tions. It is their representative within the e-mail service. Typically, this function is 
housed in the user’s computer and is referred to as a client e-mail program or a 
local network e-mail server. The author MUA formats a message and performs 
initial submission into the MHS via a MSA. The recipient MUA processes 
received mail for storage and/or display to the recipient user. 


e Mail Submission Agent (MSA): Accepts the message submitted by an MUA 
and enforces the policies of the hosting domain and the requirements of 
Internet standards. This function may be located together with the MUA or as 
a separate functional model. In the latter case, the Simple Mail Transfer 
Protocol (SMTP) is used between the MUA and the MSA. 

e Message Transfer Agent (MTA): Relays mail for one application-level hop. 
It is like a packet switch or IP router in that its job is to make routing assess- 
ments and to move the message closer to the recipients. Relaying is performed 
by a sequence of MTAs until the message reaches a destination MDA. An 

MTA also adds trace information to the message header. SMTP is used 

between MTAs and between an MTA and an MSA or MDA. 

e Mail Delivery Agent (MDA): Responsible for transferring the message from 

the MHS to the MS. 

e Message Store (MS): An MUA can employ a long-term MS. An MS can be 

located on a remote server or on the same machine as the MUA. Typically, an 

MUA retrieves messages from a remote server using POP (Post Office 

Protocol) or IMAP (Internet Message Access Protocol). 
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Figure 18.9 Function Modules and Standardized Protocols for the Internet 


Two other concepts need to be defined. An administrative management 
domain (ADMD) is an Internet e-mail provider. Examples include a department 
that operates a local mail relay (MTA), an IT department that operates an enterprise 
mail relay, and an ISP that operates a public shared e-mail service. Each ADMD can 
have different operating policies and trust-based decision making. One obvious 
example is the distinction between mail that is exchanged within an organization and 
mail that is exchanged between independent organizations. The rules for handling 
the two types of traffic tend to be quite different. 

The Domain Name System (DNS) is a directory lookup service that provides 
a mapping between the name of a host on the Internet and its numerical address. 


E-mail Threats 


RFC 4684 (Analysis of Threats Motivating DomainKeys Identified Mail) describes 
the threats being addressed by DKIM in terms of the characteristics, capabilities, 
and location of potential attackers. 


CHARACTERISTICS RFC characterizes the range of attackers on a spectrum of three 
levels of threat. 


1. At the low end are attackers who simply want to send e-mail that a recipient 
does not want to receive. The attacker can use one of a number of commercially 
available tools that allow the sender to falsify the origin address of messages. 
This makes it difficult for the receiver to filter spam on the basis of originating 
address or domain. 
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2. 


At the next level are professional senders of bulk spam mail. These attackers 
often operate as commercial enterprises and send messages on behalf of third 
parties. They employ more comprehensive tools for attack, including Mail 
Transfer Agents (MTAs) and registered domains and networks of compromised 
computers (zombies) to send messages and (in some cases) to harvest addresses 
to which to send. 


The most sophisticated and financially motivated senders of messages are those 
who stand to receive substantial financial benefit, such as from an e-mail-based 
fraud scheme. These attackers can be expected to employ all of the above 
mechanisms and additionally may attack the Internet infrastructure itself, 
including DNS cache-poisoning attacks and IP routing attacks. 


CAPABILITIES RFC 4686 lists the following as capabilities that an attacker might 


have. 
iL; 


n 


Submit messages to MTAs and Message Submission Agents (MSAs) at 
multiple locations in the Internet. 


Construct arbitrary Message Header fields, including those claiming to be 
mailing lists, resenders, and other mail agents. 


Sign messages on behalf of domains under their control. 


Generate substantial numbers of either unsigned or apparently signed messages 
that might be used to attempt a denial-of-service attack. 


. Resend messages that may have been previously signed by the domain. 


. Transmit messages using any envelope information desired. 


7. Act as an authorized submitter for messages from a compromised computer. 


8. Manipulation of IP routing. This could be used to submit messages from specific 


10. 


11. 


IP addresses or difficult-to-trace addresses, or to cause diversion of messages to a 
specific domain. 


Limited influence over portions of DNS using mechanisms such as cache 
poisoning. This might be used to influence message routing or to falsify adver- 
tisements of DNS-based keys or signing practices. 


Access to significant computing resources, for example, through the conscription of 
worm-infected “zombie” computers. This could allow the “bad actor” to perform 
various types of brute-force attacks. 


Ability to eavesdrop on existing traffic, perhaps from a wireless network. 


Location DKIM focuses primarily on attackers located outside of the administrative 
units of the claimed originator and the recipient. These administrative units frequently 
correspond to the protected portions of the network adjacent to the originator and 
recipient. It is in this area that the trust relationships required for authenticated 
message submission do not exist and do not scale adequately to be practical. 
Conversely, within these administrative units, there are other mechanisms (such as 
authenticated message submission) that are easier to deploy and more likely to be 
used than DKIM. External “bad actors” are usually attempting to exploit the “any- 
to-any” nature of e-mail that motivates most recipient MTAs to accept messages from 
anywhere for delivery to their local domain. They may generate messages without 
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signatures, with incorrect signatures, or with correct signatures from domains with 
little traceability. They may also pose as mailing lists, greeting cards, or other agents 
that legitimately send or resend messages on behalf of others. 


DKIM Strategy 


DKIM is designed to provide an e-mail authentication technique that is transparent 
to the end user. In essence, a user’s e-mail message is signed by a private key of the 
administrative domain from which the e-mail originates. The signature covers all of 
the content of the message and some of the RFC 5322 message headers. At the 
receiving end, the MDA can access the corresponding public key via a DNS and ver- 
ify the signature, thus authenticating that the message comes from the claimed 
administrative domain. Thus, mail that originates from somewhere else but claims to 
come from a given domain will not pass the authentication test and can be rejected. 
This approach differs from that of S/MIME and PGP, which use the originatotr’s pri- 
vate key to sign the content of the message. The motivation for DKIM is based on 
the following reasoning.° 


1. S/MIME depends on both the sending and receiving users employing S/MIME. 
For almost all users, the bulk of incoming mail does not use S/MIME, and the 
bulk of the mail the user wants to send is to recipients not using S/MIME. 

. S/MIME signs only the message content. Thus, RFC 5322 header information 
concerning origin can be compromised. 


N 


io) 


. DKIM is not implemented in client programs (MUAs) and is therefore transpar- 
ent to the user; the user need take no action. 


. DKIM applies to all mail from cooperating domains. 


nn & 


. DKIM allows good senders to prove that they did send a particular message 
and to prevent forgers from masquerading as good senders. 


Figure 18.10 is a simple example of the operation of DKIM. We begin with a 
message generated by a user and transmitted into the MHS to an MSA that is within 
the users administrative domain. An e-mail message is generated by an e-mail client 
program. The content of the message, plus selected RFC 5322 headers, is signed by 
the e-mail provider using the provider’s private key. The signer is associated with a 
domain, which could be a corporate local network, an ISP, or a public e-mail facility 
such as gmail. The signed message then passes through the Internet via a sequence 
of MTAs. At the destination, the MDA retrieves the public key for the incoming 
signature and verifies the signature before passing the message on to the destination 
e-mail client. The default signing algorithm is RSA with SHA-256. RSA with 
SHA-1 also may be used. 


DKIM Functional Flow 


Figure 18.11 provides a more detailed look at the elements of DKIM operation. 
Basic message processing is divided between a signing Administrative Management 
Domain (ADMD) and a verifying ADMD. At its simplest, this is between the 


>The reasoning is expressed in terms of the use of S/MIME. The same argument applies to PGP. 
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DNS = Domain Name System 
MDA = Mail Delivery Agent 
MSA = Mail Submission Agent 
MTA = Message Transfer Agent 
MUA = Message User Agent 


Figure 18.10 Simple Example of DKIM Deployment 


originating ADMD and the delivering ADMD, but it can involve other ADMDs in 
the handling path. 

Signing is performed by an authorized module within the signing ADMD and 
uses private information from a Key Store. Within the originating ADMD, this 
might be performed by the MUA, MSA, or an MTA. Verifying is performed by an 
authorized module within the verifying ADMD. Within a delivering ADMD, verify- 
ing might be performed by an MTA, MDA, or MUA. The module verifies the signa- 
ture or determines whether a particular signature was required. Verifying the signa- 
ture uses public information from the Key Store. If the signature passes, reputation 
information is used to assess the signer and that information is passed to the mes- 
sage filtering system. If the signature fails or there is no signature using the author’s 
domain, information about signing practices related to the author can be retrieved 
remotely and/or locally, and that information is passed to the message filtering sys- 
tem. For example, if the sender (e.g., gmail) uses DKIM but no DKIM signature is 
present, then the message may be considered fraudulent. 

The signature is inserted into the RFC 5322 message as an additional header 
entry, starting with the keyword Dkim-Signature. You can view examples from 
your own incoming mail by using the View Long Headers (or similar wording) 
option for an incoming message. Here is an example: 


REC 5322 Message 


Originating or Relaying ADMD: 
Sign Message with SDID 


Private 
key 
store 


(paired) 


Remote 
sender 
practices 


Public 
key 
store 


Verify 
signature 
Pass 


Assessments 


Check 
signing 
practices 


Reputation/ Message Local info 
accreditation filtering on sender 
information engine practices 


Figure 18.11 DKIM Functional Flow 


Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 
d=gmail.com; s=gamma; h=domainkey-signa- 
ture :mime-version: received: date:message- 
id:subject :from:to:content-type:con- 
tent-transfer-encoding; 
bh=5mZvQDyCRuyLb1Y2 8K4zgS2MPOemFToODBgvbJ 
7GO90s=; 
b=PcUvPSDygb4ya5Dyj1rbZGp/VyRiScuaz7TTG 
J5qw5s1M+klzv6kcf£fYdGDHZEVIW+Z 
FetuPfFLETOVhELtwH0zjSccOyPkEiblOfé6égILO 
bm3DDRm3Ys1/FVrbhVO1A+/jH9IAei 
ullIw/5iFnRbSH6qPDVv/beDOQGgAWQOfA/wF705k= 
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Before a message is signed, a process known as canonicalization is per- 
formed on both the header and body of the RFC 5322 message. Canonicalization 
is necessary to deal with the possibility of minor changes in the message made en 
route, including character encoding, treatment of trailing white space in message 
lines, and the “folding” and “unfolding” of header lines. The intent of canonical- 
ization is to make a minimal transformation of the message (for the purpose of 
signing; the message itself is not changed, so the canonicalization must be per- 
formed again by the verifier) that will give it its best chance of producing the 
same canonical value at the receiving end. DKIM defines two header canonical- 
ization algorithms (‘“simple” and “relaxed”) and two for the body (with the same 
names). The simple algorithm tolerates almost no modification, while the relaxed 
tolerates common modifications. 

The signature includes a number of fields. Each field begins with a tag consist- 
ing of a tag code followed by an equals sign and ends with a semicolon. The fields 
include the following: 


e v= DKIM version. 


e a= Algorithm used to generate the signature; must be either rsa-shal or 
rsa-sha256. 


e ¢ = Canonicalization method used on the header and the body. 


e ad = A domain name used as an identifier to refer to the identity of a respon- 
sible person or organization. In DKIM, this identifier is called the Signing 
Domain IDentifier (SDID). In our example, this field indicates that the sender 
is using a gmail address. 


e s = In order that different keys may be used in different circumstances for 
the same signing domain (allowing expiration of old keys, separate depart- 
mental signing, or the like), DKIM defines a selector (a name associated with 
a key), which is used by the verifier to retrieve the proper key during signature 
verification. 


e h = Signed Header fields. A colon-separated list of header field names that 
identify the header fields presented to the signing algorithm. Note that in our 
example above, the signature covers the domainkey-signature field. This refers 
to an older algorithm (since replaced by DKIM) that is still in use. 


° bh = The hash of the canonicalized body part of the message. This provides 
additional information for diagnosing signature verification failures. 


b = The signature data in base64 format; this is the encrypted hash code. 


18.4 RECOMMENDED READING AND WEB SITES 


[LEIBO7] provides an overview of DKIM. 


LEIBO7 Leiba, B., and Fenton, J. “DomainKeys Identified Mail (DKIM): Using Digital 
Signatures for Domain Verification.” Proceedings of Fourth Conference on E-mail 


and Anti-Spam (CEAS 07), 2007. 
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Recommended Web Sites: 


e PGP Home Page: PGP Web site by PGP Corp., the leading PGP commercial vendor. 


e International PGP Home Page: Designed to promote worldwide use of PGP. Contains 
documents and links of interest. 


e PGP Charter: Latest RFCs and Internet drafts for Open Specification PGP. 
e S/MIME Charter: Latest RFCs and Internet drafts for S/MIME. 


e DKIM: Website hosted by Mutual Internet Practices Association, this site contains a 
wide range of documents and information related to DKIM. 


e DKIM Charter: Latest RFCs and Internet drafts for DKIM. 


18.5 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


detached signature _ ; Multipurpose Internet Mail session key 
DomainKeys Identified Mail Extensions (MIME) S/MIME 


(DKIM) Pretty Good Privacy (PGP) trust 
electronic mail radix 64 ZIP 


Review Questions 


18.1 What are the five principal services provided by PGP? 
18.2. What is the utility of a detached signature? 
18.3. Why does PGP generate a signature before applying compression? 
18.4 What is R64 conversion? 
18.5 Why is R64 conversion useful for an e-mail application? 
18.6 How does PGP use the concept of trust? 
18.7 What is RFC 5322? 
18.8 What is MIME? 
18.9 What is S/MIME? 
18.10 What is DKIM? 


Problems 


18.1 PGP makes use of the cipher feedback (CFB) mode of CAST-128, whereas most sym- 
metric encryption applications (other than key encryption) use the cipher block 
chaining (CBC) mode. We have 


CBC: C; = E(K,[C;.@P)); P; = G-1O DG, C) 
CFB: C; = P; @ E(K, Ci-1); P; = C;® E{K, C-1) 
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18.6 


18.7 


18.8 


18.9 


These two appear to provide equal security. Suggest a reason why PGP uses the CFB 

mode. 

In the PGP scheme, what is the expected number of session keys generated before a 

previously created key is produced? 

In PGP, what is the probability that a user with N public keys will have at least one 

duplicate key ID? 

The first 16 bits of the message digest in a PGP signature are translated in the clear. 

a. To what extent does this compromise the security of the hash algorithm? 

b. To what extent does it in fact perform its intended function, namely, to help deter- 
mine if the correct RSA key was used to decrypt the digest? 

In Figure 18.4, each entry in the public-key ring contains an Owner Trust field that 

indicates the degree of trust associated with this public-key owner. Why is that not 

enough? That is, if this owner is trusted and this is supposed to be the owner’s public 

key, why is that trust not enough to permit PGP to use this public key? 

What is the basic difference between X.509 and PGP in terms of key hierarchies and 

key trust? 

Phil Zimmermann chose IDEA, three-key triple DES, and CAST-128 as symmetric 

encryption algorithms for PGP. Give reasons why each of the following symmetric 

encryption algorithms described in this book is suitable or unsuitable for PGP: DES, 

two-key triple DES, and AES. 

Consider radix-64 conversion as a form of encryption. In this case, there is no key. But 

suppose that an opponent knew only that some form of substitution algorithm was 

being used to encrypt English text and did not guess that it was R64. How effective 

would this algorithm be against cryptanalysis? 

Encode the text “plaintext” using the following techniques. Assume characters are 

stored in 8-bit ASCII with zero parity. 

a. Radix-64 

b. Quoted-printable 


APPENDIX 18A RADIX-64 CONVERSION 


Both PGP and S/MIME make use of an encoding technique referred to as radix-64 conver- 
sion. This technique maps arbitrary binary input into printable character output. The form of 
encoding has the following relevant characteristics: 


1. 


nN 


The range of the function is a character set that is universally representable at 
all sites, not a specific binary encoding of that character set. Thus, the characters 
themselves can be encoded into whatever form is needed by a specific system. 
For example, the character “E” is represented in an ASCII-based system as 
hexadecimal 45 and in an EBCDIC-based system as hexadecimal CS. 


The character set consists of 65 printable characters, one of which is used for 
padding. With 2° = 64 available characters, each character can be used to rep- 
resent 6 bits of input. 


No control characters are included in the set. Thus, a message encoded in radix 64 
can traverse mail-handling systems that scan the data stream for control characters. 
The hyphen character “-” is not used. This character has significance in the RFC 5322 
format and should therefore be avoided. 
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Table 18.9 Radix-64 Encoding 


6-bit Character 6-bit Character | 6-bit Character 6-bit Character 
Value Encoding Value Encoding | Value Encoding Value Encoding 


16 


ie) 


B32 g 48 
17 33 49 
18 34 50 
19 35 51 
20 36 52 
21 37 53 
22 38 54 
23 39 55 


24 40 56 


N eM #2 < GE rw fH 


25) 41 Su 
26 42 58 
27 43 Ss) 
28 44 60 
29 45 61 
30 46 62 


31 47 63 


Table 18.9 shows the mapping of 6-bit input values to characters. The character set con- 
sists of the alphanumeric characters plus “+” and “/”. The “=” character is used as the 
padding character. 

Figure 18.12 illustrates the simple mapping scheme. Binary input is processed in blocks 
of 3 octets (24 bits). Each set of 6 bits in the 24-bit block is mapped into a character. In the fig- 
ure, the characters are shown encoded as 8-bit quantities. In this typical case, each 24-bit input 
is expanded to 32 bits of output. 

For example, consider the 24-bit raw text sequence 00100011 01011100 10010001, which 
can be expressed in hexadecimal as 235C91. We arrange this input in blocks of 6 bits: 


001000 110101 110010 010001 


The extracted 6-bit decimal values are 8, 53,50, and 17. Looking these up in Table 18.9 
yields the radix-64 encoding as the following characters: I1yR. If these characters are stored 
in 8-bit ASCII format with parity bit set to zero, we have 


01001001 00110001 01111001 01010010 
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Figure 18.12 Printable Encoding of Binary Data into 
Radix-64 Format 


In hexadecimal, this is 49317952. To summarize: 


Input Data 
Binary representation 00100011 01011100 10010001 
Hexadecimal representation 235C91 


Radix-64 Encoding of Input Data 
Character representation IlyR 


ASCII code (8 bit, zero parity) 01001001 00110001 01111001 01010010 
Hexadecimal representation 49317952 
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If a secret piece of news is divulged by a spy before the time is ripe, he must be put 
to death, together with the man to whom the secret was told. 


—The Art of War, Sun Tzu 


KEY POINTS 


® IPsecurity (IPsec) is a capability that can be added to either current version 
of the Internet Protocol (IPv4 or IPv6) by means of additional headers. 


® IPsec encompasses three functional areas: authentication, confidentiality, 
and key management. 


® Authentication makes use of the HMAC message authentication code. 
Authentication can be applied to the entire original IP packet (tunnel 
mode) or to all of the packet except for the IP header (transport mode). 
® Confidentiality is provided by an encryption format known as encapsulating 
security payload. Both tunnel and transport modes can be accommodated. 


® IKE defines a number of techniques for key management. 


There are application-specific security mechanisms for a number of application 
areas, including electronic mail (S/MIME, PGP), client/server (Kerberos), Web 
access (Secure Sockets Layer), and others. However, users have security concerns 
that cut across protocol layers. For example, an enterprise can run a secure, private 
IP network by disallowing links to untrusted sites, encrypting packets that leave the 
premises, and authenticating packets that enter the premises. By implementing 
security at the IP level, an organization can ensure secure networking not only for 
applications that have security mechanisms but also for the many security-ignorant 
applications. 

IP-level security encompasses three functional areas: authentication, confiden- 
tiality, and key management. The authentication mechanism assures that a received 
packet was, in fact, transmitted by the party identified as the source in the packet 
header. In addition, this mechanism assures that the packet has not been altered in 
transit. The confidentiality facility enables communicating nodes to encrypt messages 
to prevent eavesdropping by third parties. The key management facility is concerned 
with the secure exchange of keys. 

We begin this chapter with an overview of IP security (IPsec) and an introduction 
to the IPsec architecture. We then look at each of the three functional areas in detail. 
Appendix L reviews Internet protocols. 


19.1 IP SECURITY OVERVIEW 


In 1994, the Internet Architecture Board (IAB) issued a report titled “Security in 
the Internet Architecture” (RFC 1636). The report identified key areas for 
security mechanisms. Among these were the need to secure the network 
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infrastructure from unauthorized monitoring and control of network traffic 
and the need to secure end-user-to-end-user traffic using authentication and 
encryption mechanisms. 

To provide security, the IAB included authentication and encryption as 
necessary security features in the next-generation IP, which has been issued as 
IPv6. Fortunately, these security capabilities were designed to be usable both 
with the current IPv4 and the future IPv6. This means that vendors can begin 
offering these features now, and many vendors now do have some IPsec capabil- 
ity in their products. The IPsec specification now exists as a set of Internet 
standards. 


Applications of IPsec 


IPsec provides the capability to secure communications across a LAN, across private 
and public WANs, and across the Internet. Examples of its use include: 


e Secure branch office connectivity over the Internet: A company can build a 
secure virtual private network over the Internet or over a public WAN. This 
enables a business to rely heavily on the Internet and reduce its need for 
private networks, saving costs and network management overhead. 


e Secure remote access over the Internet: An end user whose system is equipped 
with IP security protocols can make a local call to an Internet Service Provider 
(ISP) and gain secure access to a company network. This reduces the cost of toll 
charges for traveling employees and telecommuters. 


e Establishing extranet and intranet connectivity with partners: IPsec can be 
used to secure communication with other organizations, ensuring authentica- 
tion and confidentiality and providing a key exchange mechanism. 


e Enhancing electronic commerce security: Even though some Web and electronic 
commerce applications have built-in security protocols, the use of IPsec enhances 
that security. [Psec guarantees that all traffic designated by the network adminis- 
trator is both encrypted and authenticated, adding an additional layer of security 
to whatever is provided at the application layer. 


The principal feature of IPsec that enables it to support these varied applica- 
tions is that it can encrypt and/or authenticate all traffic at the IP level. Thus, all dis- 
tributed applications (including remote logon, client/server, e-mail, file transfer, Web 
access, and so on) can be secured. 

Figure 19.1 is a typical scenario of IPsec usage. An organization maintains 
LANs at dispersed locations. Nonsecure IP traffic is conducted on each LAN. For 
traffic offsite, through some sort of private or public WAN, IPsec protocols are used. 
These protocols operate in networking devices, such as a router or firewall, that con- 
nect each LAN to the outside world. The IPsec networking device will typically 
encrypt and compress all traffic going into the WAN and decrypt and decompress 
traffic coming from the WAN; these operations are transparent to workstations and 
servers on the LAN. Secure transmission is also possible with individual users who 
dial into the WAN. Such user workstations must implement the IPsec protocols to 
provide security. 
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Figure 19.1 An IP Security Scenario 
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Benefits of IPsec 


Some of the benefits of IPsec: 


e When IPsec is implemented in a firewall or router, it provides strong security 
that can be applied to all traffic crossing the perimeter. Traffic within a company 
or workgroup does not incur the overhead of security-related processing. 


e IPsec in a firewall is resistant to bypass if all traffic from the outside must use 
IP and the firewall is the only means of entrance from the Internet into the 
organization. 


e IPsec is below the transport layer (TCP, UDP) and so is transparent to 
applications. There is no need to change software on a user or server system 
when IPsec is implemented in the firewall or router. Even if IPsec is 
implemented in end systems, upper-layer software, including applications, is 
not affected. 


e IPsec can be transparent to end users. There is no need to train users on security 
mechanisms, issue keying material on a per-user basis, or revoke keying material 
when users leave the organization. 


e IPsec can provide security for individual users if needed. This is useful for offsite 
workers and for setting up a secure virtual subnetwork within an organization 
for sensitive applications. 


Routing Applications 


In addition to supporting end users and protecting premises systems and networks, 
IPsec can play a vital role in the routing architecture required for internetworking. 
[HUIT98] lists the following examples of the use of IPsec. IPsec can assure that 


e A router advertisement (a new router advertises its presence) comes from an 
authorized router. 


e A neighbor advertisement (a router seeks to establish or maintain a neighbor 
relationship with a router in another routing domain) comes from an autho- 
rized router. 


e A redirect message comes from the router to which the initial IP packet was sent. 


e A routing update is not forged. 


Without such security measures, an opponent can disrupt communications 
or divert some traffic. Routing protocols such as Open Shortest Path First (OSPF) 
should be run on top of security associations between routers that are defined 
by IPsec. 


IPsec Documents 


IPsec encompasses three functional areas: authentication, confidentiality, and key 
management. The totality of the IPsec specification is scattered across dozens of 
RFCs and draft IETF documents, making this the most complex and difficult to grasp 
of all IETF specifications. The best way to grasp the scope of IPsec is to consult the 


620 CHAPTER 19 / IP SECURITY 


latest version of the IPsec document roadmap, which as of this writing is [FRANO9]. 
The documents can be categorized into the following groups. 


Architecture: Covers the general concepts, security requirements, definitions, 
and mechanisms defining IPsec technology. The current specification is RFC 
4301, Security Architecture for the Internet Protocol. 


Authentication Header (AH): AH is an extension header to provide message 
authentication. The current specification is RFC 4302, [P Authentication 
Header. Because message authentication is provided by ESP, the use of AH is 
deprecated. It is included in IPsecv3 for backward compatibility but should 
not be used in new applications. We do not discuss AH in this chapter. 


Encapsulating Security Payload (ESP): ESP consists of an encapsulating header 
and trailer used to provide encryption or combined encryption/authentication. 
The current specification is RFC 4303, JP Encapsulating Security Payload (ESP). 


Internet Key Exchange (IKE): This is a collection of documents describing 
the key management schemes for use with IPsec. The main specification is 
RFC 4306, Internet Key Exchange (IKEv2) Protocol, but there are a number of 
related RFCs. 


Cryptographic algorithms: This category encompasses a large set of docu- 
ments that define and describe cryptographic algorithms for encryption, mes- 
sage authentication, pseudorandom functions (PRFs), and cryptographic key 
exchange. 


Other: There are a variety of other IPsec-related RFCs, including those deal- 
ing with security policy and management information base (MIB) content. 


IPsec Services 


IPsec provides security services at the IP layer by enabling a system to select 
required security protocols, determine the algorithm(s) to use for the service(s), and 
put in place any cryptographic keys required to provide the requested services. Two 
protocols are used to provide security: an authentication protocol designated by the 
header of the protocol, Authentication Header (AH); and a combined encryption/ 
authentication protocol designated by the format of the packet for that protocol, 
Encapsulating Security Payload (ESP). RFC 4301 lists the following services: 


Access control 

Connectionless integrity 

Data origin authentication 

Rejection of replayed packets (a form of partial sequence integrity) 
Confidentiality (encryption) 

Limited traffic flow confidentiality 


Transport and Tunnel Modes 


Both AH and ESP support two modes of use: transport and tunnel mode. The oper- 
ation of these two modes is best understood in the context of a description of ESP, 
which is covered in Section 19.3. Here we provide a brief overview. 
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TRANSPORT Move Transport mode provides protection primarily for upper-layer 
protocols. That is, transport mode protection extends to the payload of an IP 
packet.' Examples include a TCP or UDP segment or an ICMP packet, all of which 
operate directly above IP in a host protocol stack. Typically, transport mode is used 
for end-to-end communication between two hosts (e.g., a client and a server, or two 
workstations). When a host runs AH or ESP over IPv4, the payload is the data that 
normally follow the IP header. For IPv6, the payload is the data that normally follow 
both the IP header and any IPv6 extensions headers that are present, with the 
possible exception of the destination options header, which may be included in 
the protection. 

ESP in transport mode encrypts and optionally authenticates the IP payload 
but not the IP header. AH in transport mode authenticates the IP payload and 
selected portions of the IP header. 


TUNNEL Move Tunnel mode provides protection to the entire IP packet. To 
achieve this, after the AH or ESP fields are added to the IP packet, the entire 
packet plus security fields is treated as the payload of new outer IP packet with a 
new outer IP header. The entire original, inner, packet travels through a tunnel 
from one point of an IP network to another; no routers along the way are able to 
examine the inner IP header. Because the original packet is encapsulated, the new, 
larger packet may have totally different source and destination addresses, adding 
to the security. Tunnel mode is used when one or both ends of a security association 
(SA) are a security gateway, such as a firewall or router that implements IPsec. 
With tunnel mode, a number of hosts on networks behind firewalls may engage in 
secure communications without implementing IPsec. The unprotected packets 
generated by such hosts are tunneled through external networks by tunnel mode 
SAs set up by the IPsec software in the firewall or secure router at the boundary of 
the local network. 

Here is an example of how tunnel mode IPsec operates. Host A on a network 
generates an IP packet with the destination address of host B on another network. 
This packet is routed from the originating host to a firewall or secure router at the 
boundary of A’s network. The firewall filters all outgoing packets to determine the 
need for IPsec processing. If this packet from A to B requires IPsec, the firewall 
performs IPsec processing and encapsulates the packet with an outer IP header. The 
source IP address of this outer IP packet is this firewall, and the destination address 
may be a firewall that forms the boundary to B’s local network. This packet is now 
routed to B’s firewall, with intermediate routers examining only the outer IP 
header. At B’s firewall, the outer IP header is stripped off, and the inner packet is 
delivered to B. 

ESP in tunnel mode encrypts and optionally authenticates the entire inner IP 
packet, including the inner IP header. AH in tunnel mode authenticates the entire 
inner IP packet and selected portions of the outer IP header. 

Table 19.1 summarizes transport and tunnel mode functionality. 


'Tn this chapter, the term IP packet refers to either an IPv4 datagram or an IPv6 packet. 
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Table 19.1 Tunnel Mode and Transport Mode Functionality 
Transport Mode SA Tunnel Mode SA 


Authenticates IP payload and selected Authenticates entire inner IP packet (inner 
portions of IP header and IPv6 header plus IP payload) plus selected portions 
extension headers. of outer IP header and outer IPv6 extension 
headers. 


ESP Encrypts IP payload and any IPv6 exten- | Encrypts entire inner IP packet. 
sion headers following the ESP header. 


ESP with Encrypts IP payload and any IPv6 Encrypts entire inner IP packet. Authenticates 
Authentication | extension headers following the ESP inner IP packet. 
header. Authenticates IP payload but 
not IP header. 


19.2 IP SECURITY POLICY 


Fundamental to the operation of IPsec is the concept of a security policy applied 
to each IP packet that transits from a source to a destination. IPsec policy is 
determined primarily by the interaction of two databases, the security association 
database (SAD) and the security policy database (SPD). This section provides 
an overview of these two databases and then summarizes their use during IPsec 
operation. Figure 19.2 illustrates the relevant relationships. 


Security Associations 


A key concept that appears in both the authentication and confidentiality mecha- 
nisms for IP is the security association (SA). An association is a one-way logical con- 
nection between a sender and a receiver that affords security services to the traffic 
carried on it. If a peer relationship is needed for two-way secure exchange, then two 
security associations are required. Security services are afforded to an SA for the 
use of AH or ESP, but not both. 


Key exchange 


Security Security 
policy policy 
database database 


Security Security 
association association 


database ESP protects data database 


Figure 19.2 IPsec Architecture 
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A security association is uniquely identified by three parameters. 


Security Parameters Index (SPI): A bit string assigned to this SA and having 
local significance only. The SPI is carried in AH and ESP headers to enable the 
receiving system to select the SA under which a received packet will be 
processed. 


IP Destination Address: This is the address of the destination endpoint of the 
SA, which may be an end-user system or a network system such as a firewall or 
router. 

Security Protocol Identifier: This field from the outer IP header indicates 
whether the association is an AH or ESP security association. 


Hence, in any IP packet, the security association is uniquely identified by the 


Destination Address in the I[Pv4 or IPv6 header and the SPI in the enclosed exten- 
sion header (AH or ESP). 


Security Association Database 


In each IPsec implementation, there is a nominal” Security Association Database 
that defines the parameters associated with each SA. A security association is nor- 
mally defined by the following parameters in an SAD entry. 


Security Parameter Index: A 32-bit value selected by the receiving end of an 
SA to uniquely identify the SA. In an SAD entry for an outbound SA, the SPI 
is used to construct the packet’s AH or ESP header. In an SAD entry for an 
inbound SA, the SPI is used to map traffic to the appropriate SA. 


Sequence Number Counter: A 32-bit value used to generate the Sequence 
Number field in AH or ESP headers, described in Section 19.3 (required for all 
implementations). 


Sequence Counter Overflow: A flag indicating whether overflow of the 
Sequence Number Counter should generate an auditable event and prevent 
further transmission of packets on this SA (required for all implementations). 


Anti-Replay Window: Used to determine whether an inbound AH or ESP 
packet is a replay, described in Section 19.3 (required for all implementations). 


AH Information: Authentication algorithm, keys, key lifetimes, and related 
parameters being used with AH (required for AH implementations). 


ESP Information: Encryption and authentication algorithm, keys, initializa- 
tion values, key lifetimes, and related parameters being used with ESP 
(required for ESP implementations). 


Lifetime of this Security Association: A time interval or byte count after 
which an SA must be replaced with a new SA (and new SPI) or terminated, 
plus an indication of which of these actions should occur (required for all 
implementations). 


?Nominal in the sense that the functionality provided by a Security Association Database must be 
present in any IPsec implementation, but the way in which that functionality is provided is up to the 
implementer. 
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e IPsec Protocol Mode: Tunnel, transport, or wildcard. 


e Path MTU: Any observed path maximum transmission unit (maximum size 
of a packet that can be transmitted without fragmentation) and aging 
variables (required for all implementations). 


The key management mechanism that is used to distribute keys is coupled to 
the authentication and privacy mechanisms only by way of the Security Parameters 
Index (SPI). Hence, authentication and privacy have been specified independent of 
any specific key management mechanism. 

IPsec provides the user with considerable flexibility in the way in which IPsec 
services are applied to IP traffic. As we will see later, SAs can be combined in a 
number of ways to yield the desired user configuration. Furthermore, IPsec provides 
a high degree of granularity in discriminating between traffic that is afforded IPsec 
protection and traffic that is allowed to bypass IPsec, as in the former case relating 
IP traffic to specific SAs. 


Security Policy Database 


The means by which IP traffic is related to specific SAs (or no SA in the case of traffic 
allowed to bypass IPsec) is the nominal Security Policy Database (SPD). In its sim- 
plest form, an SPD contains entries, each of which defines a subset of IP traffic and 
points to an SA for that traffic. In more complex environments, there may be multiple 
entries that potentially relate to a single SA or multiple SAs associated with a single 
SPD entry. The reader is referred to the relevant IPsec documents for a full discussion. 

Each SPD entry is defined by a set of IP and upper-layer protocol field values, 
called selectors. In effect, these selectors are used to filter outgoing traffic in order to 
map it into a particular SA. Outbound processing obeys the following general 
sequence for each IP packet. 


1. Compare the values of the appropriate fields in the packet (the selector fields) 
against the SPD to find a matching SPD entry, which will point to zero or 
more SAs. 


. Determine the SA if any for this packet and its associated SPI. 


ow WN 


. Do the required IPsec processing (i.e., AH or ESP processing). 
The following selectors determine an SPD entry: 


e Remote IP Address: This may be a single IP address, an enumerated list or range 
of addresses, or a wildcard (mask) address. The latter two are required to support 
more than one destination system sharing the same SA (e.g., behind a firewall). 


Local IP Address: This may be a single IP address, an enumerated list or range 
of addresses, or a wildcard (mask) address. The latter two are required to sup- 
port more than one source system sharing the same SA (e.g., behind a firewall). 


e Next Layer Protocol: The IP protocol header (IPv4, IPv6, or IPv6 Extension) 
includes a field (Protocol for IPv4, Next Header for IPv6 or IPv6 Extension) 
that designates the protocol operating over IP. This is an individual protocol 
number, ANY, or for IPv6 only, OPAQUE. If AH or ESP is used, then this IP 
protocol header immediately precedes the AH or ESP header in the packet. 
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Table 19.2 Host SPD Example 
Protocol | Local IP Remote IP Action Comment 


IPS) OIL es BYPASS IKE 


ee Slo 5 BYPASS Error messages 


12S, 1.2.3.0/24 PROTECT: ESP Encrypt intranet traffic 
intransport-mode 


1.2.3.101 1.2.4.10 PROTECT: ESP Encrypt to server 
intransport-mode 


I12 SIO! 1.2.4.10 BYPASS TLS: avoid double encryption 


IS) IO) 1.2.4.0/24 DISCARD Others in DMZ 


11235, OL Hs BYPASS Internet 


e Name: A user identifier from the operating system. This is not a field in the IP 
or upper-layer headers but is available if IPsec is running on the same operat- 
ing system as the user. 


e Local and Remote Ports: These may be individual TCP or UDP port values, 
an enumerated list of ports, or a wildcard port. 


Table 19.2 provides an example of an SPD on a host system (as opposed to a 
network system such as a firewall or router). This table reflects the following config- 
uration: A local network configuration consists of two networks. The basic corporate 
network configuration has the IP network number 1.2.3.0/24. The local configura- 
tion also includes a secure LAN, often known as a DMZ, that is identified as 
1.2.4.0/24. The DMZ is protected from both the outside world and the rest of the 
corporate LAN by firewalls. The host in this example has the IP address 1.2.3.10, 
and it is authorized to connect to the server 1.2.4.10 in the DMZ. 

The entries in the SPD should be self-explanatory. For example, UDP port 500 
is the designated port for IKE. Any traffic from the local host to a remote host for 
purposes of an IKE exchange bypasses the IPsec processing. 


IP Traffic Processing 


IPsec is executed on a packet-by-packet basis. When IPsec is implemented, each 
outbound IP packet is processed by the IPsec logic before transmission, and each 
inbound packet is processed by the IPsec logic after reception and before passing 
the packet contents on to the next higher layer (e.g., TCP or UDP). We look at the 
logic of these two situations in turn. 


OvuTBOUND PacxkeTs Figure 19.3 highlights the main elements of IPsec processing 
for outbound traffic. A block of data from a higher layer, such as TCP, is passed 
down to the IP layer and an IP packet is formed, consisting of an IP header and an 
IP body. Then the following steps occur: 


1. IPsec searches the SPD for a match to this packet. 


2. If no match is found, then the packet is discarded and an error message is 
generated. 
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Figure 19.3 Processing Model for Outbound Packets 


3. If a match is found, further processing is determined by the first matching 
entry in the SPD. If the policy for this packet is DISCARD, then the packet is 
discarded. If the policy is BYPASS, then there is no further IPsec processing; 
the packet is forwarded to the network for transmission. 


4. If the policy is PROTECT, then a search is made of the SAD for a matching 
entry. If no entry is found, then IKE is invoked to create an SA with the appro- 
priate keys and an entry is made in the SA. 


un 


The matching entry in the SAD determines the processing for this packet. 
Either encryption, authentication, or both can be performed, and either 
transport or tunnel mode can be used. The packet is then forwarded to the 
network for transmission. 


INBOUND Packets Figure 19.4 highlights the main elements of IPsec processing for 
inbound traffic. An incoming IP packet triggers the IPsec processing. The following 
steps occur: 


1. IPsec determines whether this is an unsecured IP packet or one that has 
ESP or AH headers/trailers, by examining the IP Protocol field (IPv4) or 
Next Header field (IPv6). 
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Figure 19.4 Processing Model for Inbound Packets 


2. Ifthe packet is unsecured, IPsec searches the SPD for a match to this packet. 
If the first matching entry has a policy of BYPASS, the IP header is processed 
and stripped off and the packet body is delivered to the next higher layer, such 
as TCP. If the first matching entry has a policy of PROTECT or DISCARD, or 
if there is no matching entry, the packet is discarded. 


3. For a secured packet, IPsec searches the SAD. If no match is found, the 
packet is discarded. Otherwise, IPsec applies the appropriate ESP or AH 
processing. Then, the IP header is processed and stripped off and the packet 
body is delivered to the next higher layer, such as TCP. 


19.3 ENCAPSULATING SECURITY PAYLOAD 


ESP can be used to provide confidentiality, data origin authentication, connection- 
less integrity, an anti-replay service (a form of partial sequence integrity), and (lim- 
ited) traffic flow confidentiality. The set of services provided depends on options 
selected at the time of Security Association (SA) establishment and on the location 
of the implementation in a network topology. 

ESP can work with a variety of encryption and authentication algorithms, 
including authenticated encryption algorithms such as GCM. 


ESP Format 


Figure 19.5a shows the top-level format of an ESP packet. It contains the following 
fields. 
e Security Parameters Index (32 bits): Identifies a security association. 


e Sequence Number (32 bits): A monotonically increasing counter value; this 
provides an anti-replay function, as discussed for AH. 


e Payload Data (variable): This is a transport-level segment (transport mode) 
or IP packet (tunnel mode) that is protected by encryption. 


e Padding (0 — 255 bytes): The purpose of this field is discussed later. 


Pad Length (8 bits): Indicates the number of pad bytes immediately preceding 
this field. 


e Next Header (8 bits): Identifies the type of data contained in the payload data 
field by identifying the first header in that payload (for example, an extension 
header in IPv6, or an upper-layer protocol such as TCP). 
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(b) Substructure of payload data 


Figure 19.5 ESP Packet Format 
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e Integrity Check Value (variable): A variable-length field (must be an integral 
number of 32-bit words) that contains the Integrity Check Value computed 
over the ESP packet minus the Authentication Data field. 


When any combined mode algorithm is employed, the algorithm itself is 
expected to return both decrypted plaintext and a pass/fail indication for the 
integrity check. For combined mode algorithms, the ICV that would normally 
appear at the end of the ESP packet (when integrity is selected) may be omitted. 
When the ICV is omitted and integrity is selected, it is the responsibility of the com- 
bined mode algorithm to encode within the Payload Data an ICV-equivalent means 
of verifying the integrity of the packet. 

Two additional fields may be present in the payload (Figure 19.5b). An 
initialization value (IV), or nonce, is present if this is required by the encryption or 
authenticated encryption algorithm used for ESP. If tunnel mode is being used, then 
the IPsec implementation may add traffic flow confidentiality (TFC) padding after 
the Payload Data and before the Padding field, as explained subsequently. 


Encryption and Authentication Algorithms 


The Payload Data, Padding, Pad Length, and Next Header fields are encrypted by 
the ESP service. If the algorithm used to encrypt the payload requires crypto- 
graphic synchronization data, such as an initialization vector (IV), then these data 
may be carried explicitly at the beginning of the Payload Data field. If included, 
an IV is usually not encrypted, although it is often referred to as being part of 
the ciphertext. 

The ICV field is optional. It is present only if the integrity service is selected 
and is provided by either a separate integrity algorithm or a combined mode algo- 
rithm that uses an ICV. The ICV is computed after the encryption is performed. This 
order of processing facilitates rapid detection and rejection of replayed or bogus 
packets by the receiver prior to decrypting the packet, hence potentially reducing 
the impact of denial of service (DoS) attacks. It also allows for the possibility of par- 
allel processing of packets at the receiver, i.e., decryption can take place in parallel 
with integrity checking. Note that because the ICV is not protected by encryption, a 
keyed integrity algorithm must be employed to compute the ICV. 


Padding 


The Padding field serves several purposes: 


e If an encryption algorithm requires the plaintext to be a multiple of some 
number of bytes (e.g., the multiple of a single block for a block cipher), the 
Padding field is used to expand the plaintext (consisting of the Payload Data, 
Padding, Pad Length, and Next Header fields) to the required length. 


e The ESP format requires that the Pad Length and Next Header fields be right 
aligned within a 32-bit word. Equivalently, the ciphertext must be an integer 
multiple of 32 bits. The Padding field is used to assure this alignment. 


Additional padding may be added to provide partial traffic-flow confidential- 
ity by concealing the actual length of the payload. 
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Anti-Replay Service 


A replay attack is one in which an attacker obtains a copy of an authenticated 
packet and later transmits it to the intended destination. The receipt of duplicate, 
authenticated IP packets may disrupt service in some way or may have some other 
undesired consequence. The Sequence Number field is designed to thwart such 
attacks. First, we discuss sequence number generation by the sender, and then we 
look at how it is processed by the recipient. 

When a new SA is established, the sender initializes a sequence number 
counter to 0. Each time that a packet is sent on this SA, the sender increments the 
counter and places the value in the Sequence Number field. Thus, the first value to 
be used is 1. If anti-replay is enabled (the default), the sender must not allow the 
sequence number to cycle past 2°* — 1 back to zero. Otherwise, there would be 
multiple valid packets with the same sequence number. If the limit of 2°” - 1 is 
reached, the sender should terminate this SA and negotiate a new SA with a new key. 

Because IP is a connectionless, unreliable service, the protocol does not guar- 
antee that packets will be delivered in order and does not guarantee that all packets 
will be delivered. Therefore, the IPsec authentication document dictates that the 
receiver should implement a window of size W, with a default of W = 64. The right 
edge of the window represents the highest sequence number, N, so far received for 
a valid packet. For any packet with a sequence number in the range from 
N — W + 1 to N that has been correctly received (i.e., properly authenticated), the 
corresponding slot in the window is marked (Figure 19.6). Inbound processing 
proceeds as follows when a packet is received: 


1. If the received packet falls within the window and is new, the MAC is checked. 
If the packet is authenticated, the corresponding slot in the window is marked. 


nN 


. If the received packet is to the right of the window and is new, the MAC is 
checked. If the packet is authenticated, the window is advanced so that this 
sequence number is the right edge of the window, and the corresponding slot in 
the window is marked. 


3. If the received packet is to the left of the window or if authentication fails, the 
packet is discarded; this is an auditable event. 


Advance window if 
valid packet to the 


right is received 
—————— 


Fixed window size W 


3 2 ty 


N-W N+1 
Marked if valid Unmarked if valid 
packet received packet not yet received 


Figure 19.6 Anti-replay Mechanism 
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Transport and Tunnel Modes 


Figure 19.7 shows two ways in which the IPsec ESP service can be used. In the upper 
part of the figure, encryption (and optionally authentication) is provided directly 
between two hosts. Figure 19.7b shows how tunnel mode operation can be used to set 
up a virtual private network. In this example, an organization has four private 
networks interconnected across the Internet. Hosts on the internal networks use the 
Internet for transport of data but do not interact with other Internet-based hosts. By 
terminating the tunnels at the security gateway to each internal network, the configu- 
ration allows the hosts to avoid implementing the security capability. The former 
technique is supported by a transport mode SA, while the latter technique uses a 
tunnel mode SA. 

In this section, we look at the scope of ESP for the two modes. The consid- 
erations are somewhat different for IPv4 and IPv6. We use the packet formats of 
Figure 19.8a as a starting point. 


TRANSPORT MopeE ESP Transport mode ESP is used to encrypt and optionally 
authenticate the data carried by IP (e.g.,a TCP segment), as shown in Figure 19.8b. 
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(b) A virtual private network via tunnel mode 


Figure 19.7 Transport-Mode versus Tunnel-Mode Encryption 
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Figure 19.8 Scope of ESP Encryption and Authentication 


For this mode using IPv4, the ESP header is inserted into the IP packet immediately 
prior to the transport-layer header (e.g., TCP, UDP, ICMP), and an ESP trailer 
(Padding, Pad Length, and Next Header fields) is placed after the IP packet. If 
authentication is selected, the ESP Authentication Data field is added after the ESP 
trailer. The entire transport-level segment plus the ESP trailer are encrypted. 
Authentication covers all of the ciphertext plus the ESP header. 
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In the context of IPv6, ESP is viewed as an end-to-end payload; that is, it is not 
examined or processed by intermediate routers. Therefore, the ESP header appears 
after the IPv6 base header and the hop-by-hop, routing, and fragment extension 
headers. The destination options extension header could appear before or after the 
ESP header, depending on the semantics desired. For IPv6, encryption covers 
the entire transport-level segment plus the ESP trailer plus the destination options 
extension header if it occurs after the ESP header. Again, authentication covers the 
ciphertext plus the ESP header. 

Transport mode operation may be summarized as follows. 


1. At the source, the block of data consisting of the ESP trailer plus the entire 
transport-layer segment is encrypted and the plaintext of this block is replaced 
with its ciphertext to form the IP packet for transmission. Authentication is 
added if this option is selected. 


N 


. The packet is then routed to the destination. Each intermediate router needs to 
examine and process the IP header plus any plaintext IP extension headers but 
does not need to examine the ciphertext. 


3. The destination node examines and processes the IP header plus any plaintext 
IP extension headers. Then, on the basis of the SPI in the ESP header, the 
destination node decrypts the remainder of the packet to recover the plaintext 
transport-layer segment. 


Transport mode operation provides confidentiality for any application that 
uses it, thus avoiding the need to implement confidentiality in every individual 
application. One drawback to this mode is that it is possible to do traffic analysis on 
the transmitted packets. 


TUNNEL Mope ESP Tunnel mode ESP is used to encrypt an entire IP packet 
(Figure 19.8c). For this mode, the ESP header is prefixed to the packet and then 
the packet plus the ESP trailer is encrypted. This method can be used to counter 
traffic analysis. 

Because the IP header contains the destination address and possibly source 
routing directives and hop-by-hop option information, it is not possible simply to 
transmit the encrypted IP packet prefixed by the ESP header. Intermediate routers 
would be unable to process such a packet. Therefore, it is necessary to encapsulate 
the entire block (ESP header plus ciphertext plus Authentication Data, if present) 
with a new IP header that will contain sufficient information for routing but not for 
traffic analysis. 

Whereas the transport mode is suitable for protecting connections between 
hosts that support the ESP feature, the tunnel mode is useful in a configuration that 
includes a firewall or other sort of security gateway that protects a trusted network 
from external networks. In this latter case, encryption occurs only between an exter- 
nal host and the security gateway or between two security gateways. This relieves 
hosts on the internal network of the processing burden of encryption and simplifies 
the key distribution task by reducing the number of needed keys. Further, it thwarts 
traffic analysis based on ultimate destination. 

Consider a case in which an external host wishes to communicate with a host 
on an internal network protected by a firewall, and in which ESP is implemented in 
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the external host and the firewalls. The following steps occur for transfer of a trans- 
port-layer segment from the external host to the internal host. 


1. 


nN 


The source prepares an inner IP packet with a destination address of the 
target internal host. This packet is prefixed by an ESP header; then the 
packet and ESP trailer are encrypted and Authentication Data may 
be added. The resulting block is encapsulated with a new IP header (base 
header plus optional extensions such as routing and hop-by-hop options for 
IPv6) whose destination address is the firewall; this forms the outer IP 
packet. 


. The outer packet is routed to the destination firewall. Each intermediate 


router needs to examine and process the outer IP header plus any outer IP 
extension headers but does not need to examine the ciphertext. 


. The destination firewall examines and processes the outer IP header plus 


any outer IP extension headers. Then, on the basis of the SPI in the ESP 
header, the destination node decrypts the remainder of the packet to 
recover the plaintext inner IP packet. This packet is then transmitted in the 
internal network. 


. The inner packet is routed through zero or more routers in the internal 


network to the destination host. 


Figure 19.9 shows the protocol architecture for the two modes. 


19.4 COMBINING SECURITY ASSOCIATIONS 


An individual SA can implement either the AH or ESP protocol but not both. 
Sometimes a particular traffic flow will call for the services provided by both AH 
and ESP. Further, a particular traffic flow may require IPsec services between hosts 
and, for that same flow, separate services between security gateways, such as fire- 
walls. In all of these cases, multiple SAs must be employed for the same traffic flow 
to achieve the desired IPsec services. The term security association bundle refers to a 
sequence of SAs through which traffic must be processed to provide a desired set of 
IPsec services. The SAs in a bundle may terminate at different endpoints or at the 
same endpoints. 

Security associations may be combined into bundles in two ways: 


e Transport adjacency: Refers to applying more than one security protocol to 
the same IP packet without invoking tunneling. This approach to combining 
AH and ESP allows for only one level of combination; further nesting yields 
no added benefit since the processing is performed at one IPsec instance: the 
(ultimate) destination. 


Iterated tunneling: Refers to the application of multiple layers of security 
protocols effected through IP tunneling. This approach allows for multiple 
levels of nesting, since each tunnel can originate or terminate at a different 
IPsec site along the path. 
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Protocol Operation for ESP 


The two approaches can be combined, for example, by having a transport SA 
between hosts travel part of the way through a tunnel SA between security gateways. 

One interesting issue that arises when considering SA bundles is the order in 
which authentication and encryption may be applied between a given pair of endpoints 
and the ways of doing so. We examine that issue next. Then we look at combinations of 
SAs that involve at least one tunnel. 
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Authentication Plus Confidentiality 


Encryption and authentication can be combined in order to transmit an IP packet 
that has both confidentiality and authentication between hosts. We look at several 
approaches. 


ESP wiTH AUTHENTICATION Option This approach is illustrated in Figure 19.8. In 
this approach, the user first applies ESP to the data to be protected and then 
appends the authentication data field. There are actually two subcases: 


e Transport mode ESP: Authentication and encryption apply to the IP payload 
delivered to the host, but the IP header is not protected. 


e Tunnel mode ESP: Authentication applies to the entire IP packet delivered 
to the outer IP destination address (e.g., a firewall), and authentication is 
performed at that destination. The entire inner IP packet is protected by the 
privacy mechanism for delivery to the inner IP destination. 


For both cases, authentication applies to the ciphertext rather than the plaintext. 


TRANSPORT ADJACENCY Another way to apply authentication after encryption is to 
use two bundled transport SAs, with the inner being an ESP SA and the outer being 
an AH SA. In this case, ESP is used without its authentication option. Because the 
inner SA is a transport SA, encryption is applied to the IP payload. The resulting 
packet consists of an IP header (and possibly IPv6 header extensions) followed by an 
ESP. AH is then applied in transport mode, so that authentication covers the ESP plus 
the original IP header (and extensions) except for mutable fields. The advantage of 
this approach over simply using a single ESP SA with the ESP authentication option 
is that the authentication covers more fields, including the source and destination IP 
addresses. The disadvantage is the overhead of two SAs versus one SA. 


TRANSPORT-TUNNEL BUNDLE The use of authentication prior to encryption might 
be preferable for several reasons. First, because the authentication data are 
protected by encryption, it is impossible for anyone to intercept the message and 
alter the authentication data without detection. Second, it may be desirable to store 
the authentication information with the message at the destination for later 
reference. It is more convenient to do this if the authentication information applies 
to the unencrypted message; otherwise the message would have to be reencrypted 
to verify the authentication information. 

One approach to applying authentication before encryption between two 
hosts is to use a bundle consisting of an inner AH transport SA and an outer ESP 
tunnel SA. In this case, authentication is applied to the IP payload plus the IP 
header (and extensions) except for mutable fields. The resulting IP packet is then 
processed in tunnel mode by ESP; the result is that the entire, authenticated inner 
packet is encrypted and a new outer IP header (and extensions) is added. 


Basic Combinations of Security Associations 


The IPsec Architecture document lists four examples of combinations of SAs that 
must be supported by compliant IPsec hosts (e.g., workstation, server) or security 
gateways (e.g. firewall, router). These are illustrated in Figure 19.10. The lower part 
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Figure 19.10 Basic Combinations of Security Associations 
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of each case in the figure represents the physical connectivity of the elements; the 
upper part represents logical connectivity via one or more nested SAs. Each SA can 
be either AH or ESP. For host-to-host SAs, the mode may be either transport or 
tunnel; otherwise it must be tunnel mode. 

Case 1. All security is provided between end systems that implement IPsec. 
For any two end systems to communicate via an SA, they must share the appropri- 
ate secret keys. Among the possible combinations are 


a. AH in transport mode 
b. ESP in transport mode 
c. ESP followed by AH in transport mode (an ESP SA inside an AH SA) 


d. Any one of a, b, or c inside an AH or ESP in tunnel mode 


We have already discussed how these various combinations can be used to 
support authentication, encryption, authentication before encryption, and authenti- 
cation after encryption. 

Case 2. Security is provided only between gateways (routers, firewalls, etc.) 
and no hosts implement IPsec. This case illustrates simple virtual private network 
support. The security architecture document specifies that only a single tunnel SA is 
needed for this case. The tunnel could support AH, ESP, or ESP with the authenti- 
cation option. Nested tunnels are not required, because the IPsec services apply to 
the entire inner packet. 

Case 3. This builds on case 2 by adding end-to-end security. The same combi- 
nations discussed for cases 1 and 2 are allowed here. The gateway-to-gateway tunnel 
provides either authentication, confidentiality, or both for all traffic between end 
systems. When the gateway-to-gateway tunnel is ESP, it also provides a limited form 
of traffic confidentiality. Individual hosts can implement any additional IPsec ser- 
vices required for given applications or given users by means of end-to-end SAs. 

Case 4. This provides support for a remote host that uses the Internet to reach an 
organization’s firewall and then to gain access to some server or workstation behind 
the firewall. Only tunnel mode is required between the remote host and the firewall. As 
in case 1, one or two SAs may be used between the remote host and the local host. 


19.5 INTERNET KEY EXCHANGE 


The key management portion of IPsec involves the determination and distribution of 
secret keys. A typical requirement is four keys for communication between two 
applications: transmit and receive pairs for both integrity and confidentiality. The 
IPsec Architecture document mandates support for two types of key management: 


e Manual: A system administrator manually configures each system with its 
own keys and with the keys of other communicating systems. This is practical 
for small, relatively static environments. 

e Automated: An automated system enables the on-demand creation of keys 
for SAs and facilitates the use of keys in a large distributed system with an 
evolving configuration. 
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The default automated key management protocol for IPsec is referred to as 
ISAKMP/Oakley and consists of the following elements: 


¢ Oakley Key Determination Protocol: Oakley is a key exchange protocol based 
on the Diffie-Hellman algorithm but providing added security. Oakley is 
generic in that it does not dictate specific formats. 


e Internet Security Association and Key Management Protocol (GSAKMP): 
ISAKMP provides a framework for Internet key management and provides the 
specific protocol support, including formats, for negotiation of security attributes. 


ISAKMP by itself does not dictate a specific key exchange algorithm; rather, 
ISAKMP consists of a set of message types that enable the use of a variety of key 
exchange algorithms. Oakley is the specific key exchange algorithm mandated for 
use with the initial version of ISAKMP. 

In IKEv2, the terms Oakley and ISAKMP are no longer used, and there are 
significant differences from the use of Oakley and ISAKMP in IKEv1. Nevertheless, 
the basic functionality is the same. In this section, we describe the IXEv2 specification. 


Key Determination Protocol 


IKE key determination is a refinement of the Diffie-Hellman key exchange algo- 
rithm. Recall that Diffie-Hellman involves the following interaction between users 
A and B. There is prior agreement on two global parameters: q, a large prime num- 
ber; and a, a primitive root of g.A selects a random integer X,, as its private key and 
transmits to B its public key Y, = a*4 mod q. Similarly, B selects a random integer 
X, as its private key and transmits to A its public key Y; = a** mod q. Each side 
can now compute the secret session key: 


K = (Yg)*4 mod q = (Y,4)*2 mod q = a*4** mod q 
The Diffie-Hellman algorithm has two attractive features: 


e Secret keys are created only when needed. There is no need to store secret 
keys for a long period of time, exposing them to increased vulnerability. 

e The exchange requires no pre-existing infrastructure other than an agreement 
on the global parameters. 


However, there are a number of weaknesses to Diffie-Hellman, as pointed out in 
[HUIT98]. 


e It does not provide any information about the identities of the parties. 

e It is subject to a man-in-the-middle attack, in which a third party C imperson- 
ates B while communicating with A and impersonates A while communicating 
with B. Both A and B end up negotiating a key with C, which can then listen to 
and pass on traffic. The man-in-the-middle attack proceeds as 
1. B sends his public key Yz in a message addressed to A (see Figure 10.2). 


2. The enemy (E) intercepts this message. E saves B’s public key and sends a 
message to A that has B’s User ID but E’s public key Y;. This message is 


640 CHAPTER 19 / IP SECURITY 


sent in such a way that it appears as though it was sent from B’s host system. 
A receives E’s message and stores E’s public key with B’s User ID. Similarly, 
E sends a message to B with E’s public key, purporting to come from A. 


3. B computes a secret key K, based on B’s private key and Y;. A computes a 
secret key K, based on A’s private key and Y,. E computes kK, using E’s 
secret key X, and Yz and computers K> using X;, and Yy. 


4. From now on, E is able to relay messages from A to B and from B to A, 
appropriately changing their encipherment en route in such a way that 
neither A nor B will know that they share their communication with E. 


e It is computationally intensive. As a result, it is vulnerable to a clogging attack, 
in which an opponent requests a high number of keys. The victim spends 
considerable computing resources doing useless modular exponentiation 
rather than real work. 


IKE key determination is designed to retain the advantages of Diffie- 
Hellman, while countering its weaknesses. 


FEATURES OF IKE KEY DETERMINATION The IKE key determination algorithm is 
characterized by five important features: 


1. It employs a mechanism known as cookies to thwart clogging attacks. 


nN 


It enables the two parties to negotiate a group; this, in essence, specifies the global 
parameters of the Diffie-Hellman key exchange. 


3. It uses nonces to ensure against replay attacks. 
4. It enables the exchange of Diffie-Hellman public key values. 


5. It authenticates the Diffie-Hellman exchange to thwart man-in-the-middle 
attacks. 


We have already discussed Diffie-Hellman. Let us look at the remainder of 
these elements in turn. First, consider the problem of clogging attacks. In this attack, 
an opponent forges the source address of a legitimate user and sends a public Diffie- 
Hellman key to the victim. The victim then performs a modular exponentiation to 
compute the secret key. Repeated messages of this type can clog the victim’s system 
with useless work. The cookie exchange requires that each side send a pseudoran- 
dom number, the cookie, in the initial message, which the other side acknowledges. 
This acknowledgment must be repeated in the first message of the Diffie-Hellman 
key exchange. If the source address was forged, the opponent gets no answer. Thus, 
an opponent can only force a user to generate acknowledgments and not to perform 
the Diffie-Hellman calculation. 

IKE mandates that cookie generation satisfy three basic requirements: 


1. The cookie must depend on the specific parties. This prevents an attacker from 
obtaining a cookie using a real IP address and UDP port and then using it to 
swamp the victim with requests from randomly chosen IP addresses or ports. 


n 


It must not be possible for anyone other than the issuing entity to generate cook- 
ies that will be accepted by that entity. This implies that the issuing entity will use 
local secret information in the generation and subsequent verification of a 
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cookie. It must not be possible to deduce this secret information from any partic- 
ular cookie. The point of this requirement is that the issuing entity need not save 
copies of its cookies, which are then more vulnerable to discovery, but can verify 
an incoming cookie acknowledgment when it needs to. 


io) 


. The cookie generation and verification methods must be fast to thwart attacks 
intended to sabotage processor resources. 


The recommended method for creating the cookie is to perform a fast hash 
(e.g., MD5) over the IP Source and Destination addresses, the UDP Source and 
Destination ports, and a locally generated secret value. 

IKE key determination supports the use of different groups for the Diffie- 
Hellman key exchange. Each group includes the definition of the two global parame- 
ters and the identity of the algorithm. The current specification includes the following 
groups. 


e Modular exponentiation with a 768-bit modulus 


gq = 278 — 27% — 1 + 2% x (| 28 x a | + 149686) 
a=2 


e Modular exponentiation with a 1024-bit modulus 


gq = 2104 — 2960 — 1 + 2% x (2% x a] + 129093) 
a=2 


e Modular exponentiation with a 1536-bit modulus 


e Parameters to be determined 


e Elliptic curve group over 2° 


e Generator (hexadecimal): X = 7B, Y = 1C8 


e Elliptic curve parameters (hexadecimal): A = 0, Y = 7338F 


e Elliptic curve group over 2!*° 


e Generator (hexadecimal): X = 18, Y = D 
e Elliptic curve parameters (hexadecimal): A = 0, Y = 1EE9 


The first three groups are the classic Diffie-Hellman algorithm using modular 
exponentiation. The last two groups use the elliptic curve analog to Diffie-Hellman, 
which was described in Chapter 10. 

IKE key determination employs nonces to ensure against replay attacks. Each 
nonce is a locally generated pseudorandom number. Nonces appear in responses 
and are encrypted during certain portions of the exchange to secure their use. 

Three different authentication methods can be used with IKE key determination: 


e Digital signatures: The exchange is authenticated by signing a mutually 
obtainable hash; each party encrypts the hash with its private key. The hash is 
generated over important parameters, such as user IDs and nonces. 


e Public-key encryption: The exchange is authenticated by encrypting parame- 
ters such as IDs and nonces with the sender’s private key. 
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e Symmetric-key encryption: A key derived by some out-of-band mechanism 
can be used to authenticate the exchange by symmetric encryption of exchange 
parameters. 


IKEv2 ExcHANGES The IKEv?2 protocol involves the exchange of messages in 
pairs. The first two pairs of exchanges are referred to as the initial exchanges 
(Figure 19.11la). In the first exchange, the two peers exchange information 
concerning cryptographic algorithms and other security parameters they are willing 
to use along with nonces and Diffie-Hellman (DH) values. The result of this 
exchange is to set up a special SA called the IKE SA (see Figure 19.2). This SA 
defines parameters for a secure channel between the peers over which subsequent 
message exchanges take place. Thus, all subsequent IKE message exchanges are 
protected by encryption and message authentication. In the second exchange, the 
two parties authenticate one another and set up a first IPsec SA to be placed in 
the SADB and used for protecting ordinary (i.e. non-IKE) communications between 
the peers. Thus, four messages are needed to establish the first SA for general use. 


Initiator Responder 
HDR, SAil, KEi, Ni 
PS 
HDR, SAr1, KEr, Nr, [CERTREQ] 

HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} 


HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} 


(a) Initial exchanges 


HDR, SK {[N], SA, Ni, [KEi], [TSi, TSr]} 


HDR, SK {SA, Nr, [KEr], [TSi, TSr]} 


(b) CREATE_CHILD_SA exchange 


HDR, SK {[N,] [D,] [CP,] ...} 
a 


HDR, SK {[N,] [D,] [CPI ...} 
— 


(c) Informational exchange 


HDR = IKE header SK {...} = MAC and encrypt 

SAx1 = offered and chosen algorithms, DH group AUTH = Authentication 

KEx = Diffie-Hellman public key SAx2 = algorithms, parameters for IPsec SA 
Nx= nonces TSx = traffic selectors for IPsec SA 
CERTREQ = Certificate request N = Notify 

IDx = identity D = Delete 

CERT = certificate CP = Configuration 


Figure 19.11 IKEv2 Exchanges 
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The CREATE_CHILD_SA exchange can be used to establish further SAs for 
protecting traffic. The informational exchange is used to exchange management 
information, IKEv2 error messages, and other notifications. 


Header and Payload Formats 


IKE defines procedures and packet formats to establish, negotiate, modify, and 
delete security associations. As part of SA establishment, IKE defines payloads for 
exchanging key generation and authentication data. These payload formats provide 
a consistent framework independent of the specific key exchange protocol, encryp- 
tion algorithm, and authentication mechanism. 


IKE HEADER FormMéT An IKE message consists of an IKE header followed by one or 
more payloads. All of this is carried in a transport protocol. The specification dictates 
that implementations must support the use of UDP for the transport protocol. 

Figure 19.12a shows the header format for an IKE message. It consists of the 
following fields. 


e Initiator SPI (64 bits): A value chosen by the initiator to identify a unique 
IKE security association (SA). 


e Responder SPI (64 bits): A value chosen by the responder to identify a 
unique IKE SA. 


e Next Payload (8 bits): Indicates the type of the first payload in the message; 
payloads are discussed in the next subsection. 


e Major Version (4 bits): Indicates major version of IKE in use. 
e Minor Version (4 bits): Indicates minor version in use. 


Bit: 0 8 16 24 31 


Initiator’s Security Parameter Index (SPI) 


Responder’s Security Parameter Index (SPI) 


Message ID 
Length 


(a) IKE header 


Bit: 8 16 31 


0 
Next Payload RESERVED Payload Length 


(b) Generic Payload header 
Figure 19.12 IKE Formats 


644 


CHAPTER 19 / IP SECURITY 


e Exchange Type (8 bits): Indicates the type of exchange; these are discussed 
later in this section. 


e Flags (8 bits): Indicates specific options set for this IKE exchange. Three bits are 
defined so far. The initiator bit indicates whether this packet is sent by the SA ini- 
tiator. The version bit indicates whether the transmitter is capable of using a 
higher major version number than the one currently indicated. The response bit 
indicates whether this is a response to a message containing the same message ID. 


e Message ID (32 bits): Used to control retransmission of lost packets and 
matching of requests and responses. 


e Length (32 bits): Length of total message (header plus all payloads) in octets. 


IKE PayLoAb Tyres All IKE payloads begin with the same generic payload header 
shown in Figure 19.12b. The Next Payload field has a value of 0 if this is the last 
payload in the message; otherwise its value is the type of the next payload. The 
Payload Length field indicates the length in octets of this payload, including the 
generic payload header. 

The critical bit is 0 if the sender wants the recipient to skip this payload if it 
does not understand the payload type code in the Next Payload field of the previous 
payload. It is set to 1 if the sender wants the recipient to reject this entire message if 
it does not understand the payload type. 

Table 19.3 summarizes the payload types defined for IKE and lists the fields, 
or parameters, that are part of each payload. The SA payload is used to begin 


Table 19.3. IKE Payload Types 


Type Parameters 


Security Association 


Proposals 


Key Exchange 


DH Group #, Key Exchange Data 


Identification 


ID Type, ID Data 


Certificate 


Certificate Request 


Cert Encoding, Certificate Data 


Cert Encoding, Certification Authority 


Authentication 


Auth Method, Authentication Data 


Nonce Data 


Delete 


Protocol-ID, SPI Size, Notify Message Type, SPI, Notification Data 


Protocol-ID, SPI Size, # of SPIs, SPI (one or more) 


Vendor ID 


Vendor ID 


Traffic Selector 


Number of TSs, Traffic Selectors 


Encrypted 


IV, Encrypted IKE payloads, Padding, Pad Length, ICV 


Configuration 


CFG Type, Configuration Attributes 


Extensible Authentication 
Protocol 


EAP Message 
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the establishment of an SA. The payload has a complex, hierarchical structure. The 
payload may contain multiple proposals. Each proposal may contain multiple proto- 
cols. Each protocol may contain multiple transforms. And each transform may 
contain multiple attributes. These elements are formatted as substructures within 
the payload as follows. 


e Proposal: This substructure includes a proposal number, a protocol ID 
(AH, ESP, or IKE), an indicator of the number of transforms, and then a 
transform substructure. If more than one protocol is to be included in a 
proposal, then there is a subsequent proposal substructure with the same pro- 
posal number. 


e Transform: Different protocols support different transform types. The trans- 
forms are used primarily to define cryptographic algorithms to be used with a 
particular protocol. 


Attribute: Each transform may include attributes that modify or complete the 
specification of the transform. An example is key length. 


The Key Exchange payload can be used for a variety of key exchange tech- 
niques, including Oakley, Diffie-Hellman, and the RSA-based key exchange used by 
PGP. The Key Exchange data field contains the data required to generate a session 
key and is dependent on the key exchange algorithm used. 

The Identification payload is used to determine the identity of communicating 
peers and may be used for determining authenticity of information. Typically the ID 
Data field will contain an IPv4 or IPv6 address. 

The Certificate payload transfers a public-key certificate. The Certificate 
Encoding field indicates the type of certificate or certificate-related information, 
which may include the following: 


e PKCS #7 wrapped X.509 certificate 
e PGP certificate 

e DNS signed key 

e X.509 certificate—signature 

e X.509 certificate—key exchange 

e Kerberos tokens 

Certificate Revocation List (CRL) 
Authority Revocation List (ARL) 
e SPKI certificate 


At any point in an IKE exchange, the sender may include a Certificate 
Request payload to request the certificate of the other communicating entity. The 
payload may list more than one certificate type that is acceptable and more than 
one certificate authority that is acceptable. 

The Authentication payload contains data used for message authentication 
purposes. The authentication method types so far defined are RSA digital signature, 
shared-key message integrity code, and DSS digital signature. 
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The Nonce payload contains random data used to guarantee liveness during 
an exchange and to protect against replay attacks. 

The Notify payload contains either error or status information associated 
with this SA or this SA negotiation. The following table lists the IKE notify 


messages. 


Error Messages 


Status Messages 


Unsupported Critical 
Payload 

Invalid IKE SPI 
Invalid Major Version 


Invalid Syntax 


Initial Contact 

Set Window Size 
Additional TS Possible 
IPCOMP Supported 
NAT Detection Source IP 


Invalid Payload Type NAT Detection Destination IP 
Invalid Message ID Cookie 

Invalid SPI Use Transport Mode 

No Proposal Chosen HTTP Cert Lookup Supported 
Invalid KE Payload Rekey SA 

Authentication Failed ESP TFC Padding Not Supported 
Single Pair Required Non First Fragments Also 

No Additional SAS 

Internal Address Failure 

Failed CP Required 

TS Unacceptable 


Invalid Selectors 


The Delete payload indicates one or more SAs that the sender has deleted 
from its database and that therefore are no longer valid. 

The Vendor ID payload contains a vendor-defined constant. The constant is 
used by vendors to identify and recognize remote instances of their implementa- 
tions. This mechanism allows a vendor to experiment with new features while 
maintaining backward compatibility. 

The Traffic Selector payload allows peers to identify packet flows for process- 
ing by IPsec services. 

The Encrypted payload contains other payloads in encrypted form. The 
encrypted payload format is similar to that of ESP. It may include an IV if the 
encryption algorithm requires it and an ICV if authentication is selected. 

The Configuration payload is used to exchange configuration information 
between IKE peers. 

The Extensible Authentication Protocol (EAP) payload allows IKE SAs to be 
authenticated using EAP, which was discussed in Chapter 17. 
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19.6 CRYPTOGRAPHIC SUITES 


The IPsecv3 and IKEv3 protocols rely on a variety of types of cryptographic algo- 
rithms. As we have seen in this book, there are many cryptographic algorithms of 
each type, each with a variety of parameters, such as key size. To promote interoper- 
ability, two RFCs define recommended suites of cryptographic algorithms and para- 
meters for various applications. 

RFC 4308 defines two cryptographic suites for establishing virtual private net- 
works. Suite VPN-A matches the commonly used corporate VPN security used in 
older IKEv1 implementations at the time of the issuance of IKEv2 in 2005. Suite 
VPN-B provides stronger security and is recommended for new VPNs that imple- 
ment IPsecv3 and IKEv2. 

Table 19.4a lists the algorithms and parameters for the two suites. There 
are several points to note about these two suites. Note that for symmetric 


Table 19.4 Cryptographic Suites for IPsec 


ESP encryption 


VPN-A 
3DES-CBC 


VPN-B 


AES-CBC (128-bit key) 


ESP integrity 


IKE encryption 


HMAC-SHA1-96 AES-XCBC-MAC-96 


3DES-CBC AES-CBC (128-bit key) 


IKE PRF 


HMAC-SHA1 AES-XCBC-PRF-128 


IKE Integrity 


HMAC-SHA1-96 AES-XCBC-MAC-96 


1024-bit MODP 


IKE DH group 


ESP 
encryption/Integrity 


2048-bit MODP 


(a) Virtual private networks (RFC 4308) 


GCM-128 


GCM-256 


GMAC-128 


GMAC-256 


AES-GCM (128- 
bit key) 


AES-GCM 
(256-bit key) 


Null 


Null 


ESP integrity 


Null 


Null 


AES-GMAC 
(128-bit key) 


AES-GMAC 
(256-bit key) 


IKE encryption 


IKE PRF 


AES-CBC (128- 
bit key) 


HMAC-SHA-256 


AES-CBC (256- 
bit key) 


HMAC-SHA-384 


AES-CBC (128-bit 
key) 
HMAC-SHA-256 


AES-CBC 
(256-bit key) 


HMAC-SHA-384 


IKE Integrity 


HMAC-SHA-256- 
128 


HMAC-SHA-384- 
192) 


HMAC-SHA-256- 
128 


HMAC-SHA- 
384-192 


IKE DH group 


256-bit random 
1X0) 2 


384-bit random 
ECR 


256-bit random 
ECP 


384-bit random 
ECR 


IKE authentication 


ECDSA-256 


ECDSA-384 


ECDSA-256 


(b) NSA Suite B (RFC 4869) 


ECDSA-384 
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cryptography, VPN-A relies on 3DES and HMAC, while VPN-B relies exclu- 
sively on AES. Three types of secret-key algorithms are used: 


e Encryption: For encryption, the cipher block chaining (CBC) mode is used. 


e Message authentication: For message authentication, VPN-A relies on HMAC 
with SHA-1 with the output truncated to 96 bits. VPN-B relies on a variant of 
CMAC with the output truncated to 96 bits. 


e Pseudorandom function: IKEv2 generates pseudorandom bits by repeated 
use of the MAC used for message authentication. 


RFC 4869 defines four optional cryptographic suites that are compatible with 
the United States National Security Agency’s Suite B specifications. In 2005, the 
NSA issued Suite B, which defined the algorithms and strengths needed to protect 
both sensitive but unclassified (SBU) and classified information for use in its 
Cryptographic Modernization program [LATTO09]. The four suites defined in 
RFC 4869 provide choices for ESP and IKE. The four suites are differentiated by 
the choice of cryptographic algorithm strengths and a choice of whether ESP is to 
provide both confidentiality and integrity or integrity only. All of the suites offer 
greater protection than the two VPN suites defined in RFC 4308. 

Table 19.4b lists the algorithms and parameters for the two suites. As with 
RFC 4308, three categories of secret key algorithms are listed: 


e Encryption: For ESP, authenticated encryption is provided using the GCM 
mode with either 128-bit or 256-bit AES keys. For IKE encryption, CBC is 
used, as it was for the VPN suites. 


e Message authentication: For ESP, if only authentication is required, then 
GMAC is used. As discussed in Chapter 12, GMAC is simply the authentication 
portion of GMC. For IKE, message authentication is provided using HMAC 
with one of the SHA-3 hash functions. 


e Pseudorandom function: As with the VPN suites, IKEv2 in these suites gener- 
ates pseudorandom bits by repeated use of the MAC used for message 
authentication. 


For the Diffie-Hellman algorithm, the use of elliptic curve groups modulo a 
prime is specified. For authentication, elliptic curve digital signatures are listed. The 
original IKEv2 documents used RSA-based digital signatures. Equivalent or greater 
strength can be achieved using ECC with fewer key bits. 


19.7 RECOMMENDED READING AND WEB SITES 


IPv6 and IPv4 are covered in more detail in [STALO7]. [CHEN98] provides a good 
discussion of an IPsec design. [FRANOS5] is a more comprehensive treatment of IPsec. 
[PATE06] is a useful overview of IPsecv3 and IKEv2 with an emphasis on cryptographic 
aspects. 
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Recommended Web Sites: 


e NIST IPsec Project: Contains papers, presentations, and reference implemen- 


tations. 


e IPsec Maintenance and Extensions Charter: Latest RFCs and internet drafts 


for IPsec. 
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Key Terms 


anti-replay service 
Authentication Header (AH) 
Encapsulating Security 


Payload (ESP) 

Internet Security Association 
and Key Management 
Protocol (ISAKMP) 


Review Questions 


Internet Key Exchange (IKE) 

IP Security (IPsec) 

IPv4 

IPv6 

Oakley key determination 
protocol 


19.1 Give examples of applications of IPsec. 
19.2 What services are provided by IPsec? 
19.3. What parameters identify an SA and what parameters characterize the nature of a 


particular SA? 


replay attack 

security association (SA) 
transport mode 

tunnel mode 


19.4 What is the difference between transport mode and tunnel mode? 
19.5 What is a replay attack? 

19.6 Why does ESP include a padding field? 

19.7 What are the basic approaches to bundling SAs? 
19.8 What are the roles of the Oakley key determination protocol and ISAKMP 


in IPsec? 
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Problems 

19.1 Describe and explain each of the entries in Table 19.2. 

19.2 Draw a figure similar to Figure 19.8 for AH. 

19.3 List the major security services provided by AH and ESP, respectively. 

19.4 In discussing AH processing, it was mentioned that not all of the fields in an IP header 
are included in MAC calculation. 

a. For each of the fields in the [Pv4 header, indicate whether the field is immutable, 
mutable but predictable, or mutable (zeroed prior to ICV calculation). 

b. Do the same for the IPv6 header. 

c. Do the same for the IPv6 extension headers. 

In each case, justify your decision for each field. 

19.5 Suppose that the current replay window spans from 120 to 530. 

a. Ifthe next incoming authenticated packet has sequence number 105, what will the 
receiver do with the packet, and what will be the parameters of the window after 
that? 

b. Ifinstead the next incoming authenticated packet has sequence number 440, what 
will the receiver do with the packet, and what will be the parameters of the 
window after that? 

c. Ifinstead the next incoming authenticated packet has sequence number 540, what 
will the receiver do with the packet, and what will be the parameters of the 
window after that? 

19.6 When tunnel mode is used, a new outer IP header is constructed. For both IPv4 and 
IPv6, indicate the relationship of each outer IP header field and each extension 
header in the outer packet to the corresponding field or extension header of the inner 
IP packet. That is, indicate which outer values are derived from inner values and 
which are constructed independently of the inner values. 

19.7. End-to-end authentication and encryption are desired between two hosts. Draw 
figures similar to Figure 19.8 that show each of the following. 

a. Transport adjacency with encryption applied before authentication. 

b. A transport SA bundled inside a tunnel SA with encryption applied before 
authentication. 

c. A transport SA bundled inside a tunnel SA with authentication applied before 
encryption. 

19.8 The IPsec architecture document states that when two transport mode SAs are bun- 
dled to allow both AH and ESP protocols on the same end-to-end flow, only one 
ordering of security protocols seems appropriate: performing the ESP protocol 
before performing the AH protocol. Why is this approach recommended rather than 
authentication before encryption? 

19.9 For the IKE key exchange, indicate which parameters in each message go in which 
ISAKMP payload types. 

19.10 Where does IPsec reside in a protocol stack? 
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A.l 
A.2 
A3 
AA 
A.5 
A.6 
A.7 
A8 
Ad 


AND NETWORK SECURITY 


Sage Computer Algebra Projects 
Hacking Project 

Block Cipher Projects 
Laboratory Exercises 

Research Projects 

Programming Projects 

Practical Security Assessments 
Writing Assignments 


Reading/Report Assignments 


651 


652 APPENDIX A / PROJECTS FOR TEACHING CRYPTOGRAPHY 


Analysis and observation, theory and experience must never disdain or exclude each other; on the 


contrary, they support each other. 


—On War, Carl Von Clausewitz 


Many instructors believe that research or implementation projects are crucial to the 
clear understanding of cryptography and network security. Without projects, it may 
be difficult for students to grasp some of the basic concepts and interactions among 
components. Projects reinforce the concepts introduced in the book, give the stu- 
dent a greater appreciation of how a cryptographic algorithm or protocol works, and 
can motivate students and give them confidence that they are capable of not only 
understanding but implementing the details of a security capability. 


In this text, I have tried to present the concepts of cryptography and network 


security as clearly as possible and have provided numerous homework problems to 
reinforce those concepts. However, many instructors will wish to supplement this 
material with projects. This appendix provides some guidance in that regard and 
describes support material available in the Instructor’s Resource Center (IRC) for 
this book, accessible to instructors from Prentice Hall. The support material covers 
nine types of projects: 


Sage computer algebra projects 
Hacking project 

Block cipher projects 
Laboratory exercises 

Research projects 
Programming projects 
Practical security assessments 
Writing assignments 
Reading/report assignments 


A.1 SAGE COMPUTER ALGEBRA PROJECTS 


One of the most important new features for this edition is the use of Sage for cryp- 
tographic examples and homework assignments. Sage is an open-source, multiplat- 
form, freeware package that implements a very powerful, flexible, and easily learned 
mathematics and computer algebra system. A computer algebra system (CAS) is 
software that can perform symbolic as well as numerical calculations. CASs have 
been used for teaching since their inception some decades ago, and there is now a 
considerable literature on their use. A CAS is a natural tool for extending the learn- 
ing experience in a cryptography course. 


Unlike competing systems such as Mathematica, Maple, and MATLAB, there 


are no licensing agreements or fees involved with Sage. Thus, Sage can be made 
available on computers and networks at school, and students can individually 
download the software to their own personal computers for use at home. Another 
advantage of using Sage is that students learn a powerful, flexible tool that can 
be used for virtually any mathematical application, not just cryptography. The Sage 
Web site (http://www.sagemath.org) provides considerable documentation on how 
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to install, set up, and use Sage on a variety of computers and how to use it online via 
the Web. 


The use of Sage can make a significant difference to the teaching of the mathe- 


matics of cryptographic algorithms. Appendix B provides a large number of 
examples of the use of Sage covering many cryptographic concepts. Appendix C lists 
exercises in each of these topic areas to enable the student to gain hands-on experi- 
ence with cryptographic algorithms. Copies of both appendices are available online 
so that students do not have to key in lines of code that are printed in the appendices. 


The IRC contains solutions to all of the exercises in Appendix C. 
Dan Shumow of Microsoft and the University of Washington developed all of 


the examples and assignments in Appendices B and C. 


A.2, HACKING PROJECT 


The aim of this project is to hack into a corporation’s network through a series of 
steps. The Corporation is named Extreme In Security Corporation. As the name in- 
dicates, the corporation has some security holes in it, and a clever hacker is able to 
access critical information by hacking into its network. The IRC includes what is 
needed to set up the Web site. The student’s goal is to capture the secret information 
about the price on the quote the corporation is placing next week to obtain a con- 
tract for a governmental project. 


The student should start at the Web site and find his or her way into the net- 


work. At each step, if the student succeeds, there are indications as to how to pro- 
ceed on to the next step as well as the grade until that point. 


ow re = 


The project can be attempted in three ways: 


. Without seeking any sort of help 
. Using some provided hints 
. Using exact directions 


The IRC includes the files needed for this project: 


. Web Security project 
. Web Hacking exercises (XSS and Script-attacks) covering client-side and serv- 


er-side vulnerability exploitations respectively 


. Documentation for installation and use for the above 
. A PowerPoint file describing Web hacking. This file is crucial to understanding 


how to use the exercises since it clearly explains the operation using screen 
shots. 


This project was designed and implemented by Professor Sreekanth Malladi 


of Dakota State University. 


A.3 BLOCK CIPHER PROJECTS 


This is a lab that explores the operation of the AES encryption algorithm by tracing 
its execution, computing one round by hand, and then exploring the various block 
cipher modes of use. The lab also covers DES. In both cases, an online Java applet is 
used (or can be downloaded) to execute AES or DES. 
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For both AES and DES, the lab is divided into three separate parts: 


Block cipher internals: This part involves encrypting plaintext and analyzing 
the intermediate results after each round. There is an online calculator for 
both AES and DES that provides the intermediate results and the final 
ciphertext. 


Block cipher round: This part involves calculating one round by hand and 
comparing the results to those produced by the calculator. 


Block cipher modes of use: Enables the student to compare the operation of 
CBC and CFB modes. 


The IRC contains the .html and . jar files needed to set up these labs on 
your own Web site. Alternatively, the material is available from the Student 
Resources section of this book’s Web site. Click on the rotating globe. 

Lawrie Brown of the Australian Defence Force Academy developed these 
projects. 


A.4 LABORATORY EXERCISES 


Professor Sanjay Rao and Ruben Torres of Purdue University have prepared a set 
of laboratory exercises that are included in the IRC. These are implementation pro- 
jects designed to be programmed on Linux but could be adapted for any Unix envi- 
ronment. These laboratory exercises provide realistic experience in implementing 
security functions and applications. 


A.5 RESEARCH PROJECTS 


An effective way of reinforcing basic concepts from the course and for teaching stu- 
dents research skills is to assign a research project. Such a project could involve a lit- 
erature search as well as an Internet search of vendor products, research lab 
activities, and standardization efforts. Projects could be assigned to teams or, for 
smaller projects, to individuals. In any case, it is best to require some sort of project 
proposal early in the term, giving the instructor time to evaluate the proposal for 
appropriate topic and appropriate level of effort. Student handouts for research 
projects should include 


e A format for the proposal 

e A format for the final report 

e Aschedule with intermediate and final deadlines 
e A list of possible project topics 


The students can select one of the topics listed in the IRC or devise their own 
comparable project. The IRC includes a suggested format for the proposal and final 
report as well as a list of fifteen possible research topics. 
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A.6 PROGRAMMING PROJECTS 


The programming project is a useful pedagogical tool. There are several attractive 
features of stand-alone programming projects that are not part of an existing security 
facility: 


J. The instructor can choose from a wide variety of cryptography and network 
security concepts to assign projects. 

2. The projects can be programmed by the students on any available computer 
and in any appropriate language; they are platform and language independent. 

3. The instructor need not download, install, and configure any particular infra- 
structure for stand-alone projects. 


There is also flexibility in the size of projects. Larger projects give students 
more a sense of achievement, but students with less ability or fewer organizational 
skills can be left behind. Larger projects usually elicit more overall effort from the 
best students. Smaller projects can have a higher concepts-to-code ratio and, 
because more of them can be assigned, the opportunity exists to address a variety of 
different areas. 

Again, as with research projects, the students should first submit a proposal. 
The student handout should include the same elements listed in the preceding sec- 
tion. The IRC includes a set of twelve possible programming projects. 

The following individuals have supplied the research and programming 
projects suggested in the IRC: Henning Schulzrinne of Columbia University; Cetin 
Kaya Koc of Oregon State University; and David M. Balenson of Trusted Informa- 
tion Systems and George Washington University. 


A.7 PRACTICAL SECURITY ASSESSMENTS 


Examining the current infrastructure and practices of an existing organization is 
one of the best ways of developing skills in assessing its security posture. The IRC 
contains a list of such activities. Students, working either individually or in small 
groups, select a suitable small- to medium-sized organization. They then interview 
some key personnel in that organization in order to conduct a suitable selection of 
security risk assessment and review tasks as it relates to the organization’s IT infra- 
structure and practices. As a result, they can then recommend suitable changes, 
which can improve the organization’s IT security. These activities help students 
develop an appreciation of current security practices and the skills needed to review 
these and recommend changes. 

Lawrie Brown of the Australian Defence Force Academy developed these 
projects. 


A.8 WRITING ASSIGNMENTS 


Writing assignments can have a powerful multiplier effect in the learning process in 
a technical discipline such as cryptography and network security. Adherents of the 
Writing Across the Curriculum (WAC) movement (http://wac.colostate.edu/) report 
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substantial benefits of writing assignments in facilitating learning. Writing assign- 
ments lead to more detailed and complete thinking about a particular topic. In addi- 
tion, writing assignments help to overcome the tendency of students to pursue a 
subject with a minimum of personal engagement, just learning facts and problem- 
solving techniques without obtaining a deep understanding of the subject matter. 

The IRC contains a number of suggested writing assignments, organized by 
chapter. Instructors may ultimately find that this is an important part of their 
approach to teaching the material. I would greatly appreciate any feedback on this 
area and any suggestions for additional writing assignments. 


A.9 READING/REPORT ASSIGNMENTS 


Another excellent way to reinforce concepts from the course and to give students 
research experience is to assign papers from the literature to be read and analyzed. 
The student is then asked to write a brief report on the assigned paper. The IRC 
includes a suggested list of papers, one or two per chapter, to be assigned. The IRC 
provides a PDF copy of each of the papers. The IRC also includes a suggested 
assignment wording. 
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This appendix contains a number of examples that illustrate cryptographic concepts, 
organized by the chapter in which those concepts were discussed. All the examples 
are in Sage.' See Appendix C for how to get started using Sage and for a brief intro- 
duction to Sage syntax and operations. We begin with a brief introduction to some 
basic Sage matrix and linear algebra operations. 

You should be able to follow the examples in this section as written. However, 
if you have difficulty interpreting the Sage code, please refer to Section C.2 in 
Appendix C. 


B.1 LINEAR ALGEBRA AND MATRIX FUNCTIONALITY 


Sage includes linear algebra and matrix functionality. The following shows some of 
the basic functionality applicable to cryptography. 

In Sage you specify a matrix as a list of lists of numbers, passed to the matrix 
function. For example, passing a list of lists of integers as follows: 


sage: M = matrix([[1, 3],[7,9]]); M 
[1 3] 
[7 9] 


Alternately, passing a list of lists of rationals as follows: 


sage: M = matrix([[1/2, 2/3, 3/4],[5, 7, 8]]); M 
[1/2 2/3 3/4] 
[ 5 7 8] 


You can specify that the input should be reduced by a modulus, using the 
IntegerModRing (functionality to be described later) 


Sage: R = IntegerModRing (100) 
sage: M = matrix(R, [[1],[102],[1003]]); M 


Or that the input should be considered in a finite field (also to be described 
later.) 


sage: F = GF(2); 
sage: M = matrix(F, [[1, 2, 0, 3]]); M 
[L. 0-041] 


'AII of the Sage code in this appendix is available online at this book’s Web site in .sage files, so that you 
can load and execute the programs if you wish. See Preface for access information. 
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Sage also supports multiplication, addition, and inversion of matrices as follows: 


sage: Ml = matrix([[1, 2],[3,4]]); 
sage: M2 = matrix([[1,-1],[1, 1]]); 
sage: M1*M2 
[3 1] 
[7 1] 
sage: Ml + M2 
[2 1] 
4 5] 
sage: M2%-1 
[ 1/2 1/2] 
[-1/2 1/2] 


B.2, CHAPTER 2: CLASSICAL ENCRYPTION 


The following functions are useful for classical cipher examples and exercises: 


en_alphabet = "abcdefghijklmnopqrstuvwxyz" 

# 

# This function returns true if and only if the character 
c is an 

# alphabetic character 

# 


def is_alphabetic_char(c): 
return (c.lower() in en_alphabet) 


# 
# This function converts a single character into its 
numeric value 
# 
def char_to_num(c): 
return en_alphabet.index(c.lower () ) 


# 

# This function returns the character corresponding to x 
mod 26 

# in the English alphabet 

# 


def num_to_char (x): 
return en_alphabet[x % 26] 


Example 1: Implement Sage encryption/decryption functions that take a key 
(as an integer in 0, 1, 2,... ,25), and a string. The function should only operate 
on the characters ‘a’, ‘b’, ... ‘z’ (both upper and lower case), and it should leave 
any other characters unchanged. 
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Solution: 
def CaesarEncrypt(k, plaintext): 
ciphertext = "" 
for j in xrange(len(plaintext)): 
p = plaintext[j] 


if is_alphabetic_char(p): 


x = (k + char_to_num(p)) % 26 
c = num_to_char (x) 

else: 
c =p 


ciphertext += c 


return ciphertext 


def CaesarDecrypt(k, ciphertext): 
plaintext = "" 
for j in xrange(len(ciphertext) ): 
c = ciphertext [j] 


if is_alphabetic_char(c): 
x = (char_to_num(c) - k) % 26 
num_to_char (x) 


ae: 
Il 


prc 


plaintext += p 
return plaintext 
Example 2: Implement a function that performs a brute force attack on a 
ciphertext, it should print a list of the keys and associated decryptions. It 


should also take an optional parameter that takes a substring and only prints 
out potential plaintexts that contain that decryption. 


Solution: 


def BruteForceAttack (ciphertext, keyword=None) : 


for k in xrange(26): 
plaintext = CaesarDecrypt(k, ciphertext) 


if (None==keyword) or (keyword in plaintext): 
print "key", k, "decryption", plaintext 


return 
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Example 3: Show the output of your encrypt function (Example 1) on the fol- 
lowing (key, plaintext) pairs: 


e k = 16 plaintext = “Get me a vanilla ice cream, make it a double.” 
e k = 15 plaintext = “I don’t much care for Leonard Cohen.” 
e k = 16 plaintext = “I like root beer floats.” 


Solution: 


sage: k = 6; plaintext = 'Get me a vanilla ice cream, 
make it a double.' 

sage: CaesarEncrypt(k, plaintext) 

'mkz sk g bgtorrg oik ixkgs, sgqk oz g juahrk.' 


sage: k = 15; plaintext = "I don’t much care for 
Leonard Cohen." 

sage: CaesarEncrypt(k, plaintext) 

"x sdc'i bjrw rpgt udg atdcpgs rdwtc." 


sage: k = 16; plaintext = "I like root beer floats." 
sage: CaesarEncrypt(k, plaintext) 
'y byau heej ruuh vbeqji.' 


Example 4: Show the output of your decrypt function (Example 1) on the 
following (key, ciphertext) pairs: 


e k = 12 ciphertext = ‘nduzs ftq buzq oazqe.’ 
e k = 3 ciphertext = “fdhvdu qhhgv wr orvh zhljkw.” 
e k = 20 ciphertext = “ufgihxm uly numnys.” 


Solution: 


sage: k = 12; ciphertext = "nduzs ftq buzq oazqe." 
sage: CaesarDecrypt(k, ciphertext) 
‘bring the pine cones.' 


sage: k = 3; ciphertext = "fdhvdu gqhhgv wr orvh 
zhijkw." 

sage: CaesarDecrypt(k, ciphertext) 

‘caesar needs to lose weight. ' 


sage: k = 20; ciphertext = "ufgihxm uly numnys." 
sage: CaesarDecrypt(k, ciphertext) 
‘almonds are tastey.' 


Example 5: Show the output of your attack function (Example 2) on the following 
ciphertexts, if an optional keyword is specified, pass that to your attack function: 


° ciphertext = ‘gryy guru gob tab gb nzoebfr puncry.’ keyword = ‘chapel’ 
° ciphertext = ‘wziv kyv jyfk nyve kyv tpdsrcj tirjy.’ keyword = ‘cymbal’ 
° ciphertext = ‘baeeq klwosjl osk s esf ozg cfwo lgg emuz.’ no keyword 
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Solution: 


sage: ciphertext = 'gryy gurz gb tb gb nzoebfr puncry.' 
sage: BruteForceAttack(ciphertext, 'chapel') 
key 13 decryption tell them to go to ambrose chapel. 


sage: ciphertext = 'wziv kyv jyfk nyve kyv tpdsrcj tirjy.' 
sage: BruteForceAttack(ciphertext, 'cymbal') 
key 17 decryption fire the shot when the cymbals crash. 


sage: ciphertext = 'baeeq klwosjl osk s esf ozg cfwo lgg emuz.' 
sage: BruteForceAttack (ciphertext) 


key 0 decryption baeeq klwosjl osk s esf ozg cfwo lgg emuz. 
key 1 decryption azddp jkvnrik nrj r dre nyf bevn kff dlty. 
key 2 decryption zycco ijumqhj mqi q cqd mxe adum jee cksx. 
key 3 decryption yxbbn hitlpgi lph p bpc lwd zctl idd bjrw. 
key 4 decryption xwaam ghskofh kog o aob kvc ybsk hcc aiqv. 
key 5 decryption wvzzl fgrjneg jnf n zna jub xarj gbb zhpu. 
key 6 decryption vuyyk efqimdf ime m ymz ita wzqi faa ygot. 
key 7 decryption utxxj dephlice hld 1 xly hsz vyph ezz xfns. 
key 8 decryption tswwi cdogkbd gkc k wkx gry uxog dyy wemr. 
key 9 decryption srvvh benfjac fjb j vjw fqx twnf cxx vdlq. 
key 10 decryption rquug abmeizb eia i uiv epw svme bww uckp. 
key 11 decryption qpttf zaldhya dhz h thu dov ruld avv tbjo. 
key 12 decryption posse yzkcgxz cgy g sgt cnu qtke zuu sain. 
key 13 decryption onrrd xyjbfwy bfx f rfs bmt psjb ytt rzhm. 
key 14 decryption nmqqc wxiaevx aew e ger als oria xss qygl. 
key 15 decryption mlppb vwhzduw zdv d pdq zkr nghz wrr pxfk. 
key 16 decryption lkooa uvgyctv ycu c ocp yjq mpgy vqq owej. 
key 17 decryption kjnnz tufxbsu xbt b nbo xip lofx upp nvdi. 
key 18 decryption jimmy stewart was a man who knew too much. 
key 19 decryption ihllx rsdvzqs vzr z lzm vgn jmdv snn ltbg. 
key 20 decryption hgkkw qrcuypr uyq y kyl ufm ilcu rmm ksaf. 
key 21 decryption gfjjv pqbtxoq txp x jxk tel hkbt qll jrze. 
key 22 decryption feiiu opaswnp swo w iwj sdk gjas pkk iqyd. 
key 23 decryption edhht nozrvmo rvn v hvi rej fizr ojj hpxc. 
key 24 decryption dcggs mnyquln qum u guh qbi ehyq nii gowb. 
key 25 decryption cbffr lmxptkm ptl t ftg pah dgxp mhh fnva. 


B.3 CHAPTER 3: BLOCK CIPHERS AND THE DATA 


ENCRYPTION STANDARD 


Example 1: This example implements simplified DES, which is described in 
Appendix G. 


# 

# The Expansions/Permutations are stored as lists of 
bit positions 

# 
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P10_data = [3, 5, 2, 7, 4, 10, 1, 9, 8, 6]; 
P8_data = [6, 3, 7, 4, 8, 5, 10, 9]; 


LS1_ data = [2% a 4, Dy 1] , 
LS2_ data a [3; 4, Dy Ly 2] , 
IP data = [2, 6, 3, 1, 4, 8, 5, 7); 
TPinv_data = [4, 1, 3, 5, 7, 2, 8, 6]; 
EP_data = [4, 1, 2, 3, 2, 3, 4, 1]; 
P4_data = [2, 4, 3, 1]; 
Sw_data = [5, 6, 7, 8, 1, 2, 3, 4]; 
# 
# SDES lookup tables 
# 
SO_data = [[1, 0, 3, 2], 

[3, 2, dey Ol, 

[0, ay dy 3], 

[35 oop 34 2)]; 
Sl_data = [[0, 1, 2, 3], 

[25 0, Ty 33 

[sy Oy Ly “O15 

(25, L;, OF S113 


def ApplyPermutation(X, permutation): 
1a Wom 
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This function takes a permutation list (list of 


bit positions.) 


And outputs a bit list with the bits taken from X. 


nun 


# permute the list X 
1 = len(permutation) ; 


return [X[permutation[j]-1] for j in xrange(1)]; 


def ApplySBox(X, SBox): 


punn 
This function Applies the SDES SBox (by table 
look up 

r = 2*X[0] + X[3]; 

c = 2*X[1] + X[2]; 

o = SBox[r][c]; 

return [o & 2, 0 & 1]; 
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# 
# Each of these functions uses ApplyPermutation 
# and a permutation list to perform an SDES 
# Expansion/Permutation 
# 
def P10(X): 
return ApplyPermutation(X, P10_data); 
def P8(X): 
return ApplyPermutation(X, P8_data); 
def IP(X): 


return ApplyPermutation(X, IP_data); 


def IPinv(X): 
return ApplyPermutation(X, IPinv_data); 


def EP(X): 

return ApplyPermutation(X, EP_data); 
def P4(X): 

return ApplyPermutation(X, P4_data); 
def SW(X): 

return ApplyPermutation(X, SW_data); 
def LS1(X): 

return ApplyPermutation(X, LS1_ data); 
def LS2(X): 

return ApplyPermutation(X, LS2_ data); 
# 
# These two functions perform the SBox substitutions 
# 
def SO(X): 

return ApplySBox(X, SO_data); 
def S1(X): 

return ApplySBox(X, S1_data); 


def concatenate(left, right): 
yun 
Joins to bit lists together. 
ret = [left[j] for j in xrange(len(left))]; 
ret.extend(right) ; 
return. rev; 


def LeftHalfBits (block) : 
ec wow 
Returns the left half bits from block. 


mun 
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1 = len(block) ; 
return [block[j] for j in xrange(1/2)]; 


def RightHalfBits (block) : 
a woo 
Returns the right half bits from block. 
1 = len(block) ; 
return [block[j] for j in xrange(1/2, 1)]; 


def XorBlock(block1l, block2): 
yuen 
Xors two blocks together. 
1 = len(block1) ; 
if (1 != len(block2)): 
raise ValueError, "XorBlock arguments must be 
same length" 
return [(block1[j]+block2[j]) % 2 for j in 
xrange(1)]; 


def SDESKeySchedule(K): 
1a wom 
Expands an SDES Key (bit list) into the two round 
keys. 


mun 


temp_K = P10(K); 


left_temp_K = LeftHalfBits(temp_K) ; 
right_temp_K = RightHalfBits(temp_K) ; 


Kileft = LS1(left_temp_K); 
Kiright = LS1(right_temp_K) ; 


Kitemp = concatenate(Kileft, Kiright) ; 
Kl = P8(Kitemp) ; 


K2left = LS2(Klileft); 
K2right = LS2(Klright) ; 


K2temp = concatenate (K2left, K2right) ; 
K2 = P8(K2temp); 
return (K1, K2); 


def f_K(block, K): 
a Won 
Performs the £_K function supplied block and K. 
left_block = LeftHalfBits (block) ; 
right_block = RightHalfBits (block) ; 
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temp_block1 EP (right_block) ; 


temp_block2 = XorBlock(temp_blockl, K); 


left_temp_block2 = LeftHalfBits(temp_block2) ; 
right_temp_block2 = RightHalfBits(temp_block2) ; 


SO_out SO (left_temp_block2) ; 
Sl_out = S1(right_temp_block2); 


— 


temp_block3 = concatenate(SO_out, Sl_out); 


temp_block4 = P4(temp_block3) 


temp_block5 = XorBlock(temp_block4, left_block) ; 


output_block = concatenate (temp_block5, 
right_block) 


return output_block; 


def SDESEncrypt (plaintext_block, K): 
¢ nono 
Performs a single SDES plaintext block encryption. 
(Given plaintext and key as bit lists.) 


(K1, K2) = SDESKeySchedule(K) ; 


temp_blockl = IP(plaintext_block) ; 


temp_block2 £_K(temp_blockl, K1); 


temp_block3 SW(temp_block2) ; 


temp_block4 f£_K(temp_block3, K2); 


output_block = IPinv(temp_block4) ; 


return output_block; 


B.4. CHAPTER 4: BASIC CONCEPTS IN NUMBER THEORY AND 


FINITE FIELDS 


Example 1: The Euclidean algorithm for the greatest common divisor 


def EUCLID(a,b): 
¢ noone 
The Euclidean algorithm for finding the gcd of a and b. 
This algorithm assumes that a > b => 0 


INPUT: 
a - positive integer 


b - nonnegative integer less than a 
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OUTPUT: 


g - greatest common divisor of a and b 


nun 


if (b < 0) or ( a <= b): 
raise ValueError, "Expected 0 < a < jb" 


(A, B) = (a,b); 


while (True): 


if (0 == B): 
return A; 

R= A % B; 

A = B; 

B= RF 


Example 2: The extended Euclidean algorithm for the greatest common 
divisor 


def EXTENDED _EUCLID(m,b) : 

¢ Woo 
The extended Euclidean algorithm to find gcd(m,b). 
The input is expected to be such that 0 <= b < m. 


INPUT: 

m - positive integer 

b - nonnegative integer less than m 
OUTPUT: 


(g, b_inv) - g is the gcd of m and b, b_inv is 
the multiplicative inverse of b mod m. 


mun 


LE (ini <b) or “Cb~<..0) 


raise ValueError, "Expected input (0 < b < m)" 


(A1,A2,A3) = (1,0,m); 
(B1,B2,B3) = (0,1,b); 
while (True): 

if (0 == B3) 


1f (L == B3): 
return (B3, B2) 


Q = floor (A3/B3) 


(T1,T2,T3) = (A1-Q*B1, A2-Q*B2, A3-Q*B3) 
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(Al, A2, A3) (B1, B2, B3) 
(Bl, B2,; B3). = (TL, T2, 73) 


Example 3: Euclidean algorithm to find gcd of polynomials (with coefficients 
in a field) 


def POLYNOMIAL FUCLID(A, B): 
punn 
Euclidian algorithm for polynomial GCD: 
Given two polynomials over the same base field, 
Assuming degree(A) => degree(B) => 0. 


INPUT: 


A - polynomial over a field. 


B - polynomial over the same field as A, and 0 <= 
degree(B) <= degree(A). 


OUTPUT: 


G - greatest common divisor of A and B. 


degA = A.degree(); 
degB = B.degree(); 


if ((degB < 0) or (degA < degB)): 
raise ValueError, "Expected 0 <= degree(B) <=d 
gree(A)" 


while(True) : 


af (Q == B) 
return A; 
= A % B; 
= B; 
B = R; 


Example 4; Extended Euclidean algorithm for the gcd of two polynomials 
(with coefficients in the same field) 


def POLYNOMIAL EXTENDED _EUCLID(m, b): 
pun 
Extended Euclidian algorithm for polynomial GCD: 
Given two polynomials over the same base field, 
Assuming degree(m) => degree(b) => 0 


INPUT: 


m - polynomial over a field. 
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b - polynomial over the same field as A, and 0 <= 
degree(B) <= degree(M). 


OUTPUT: 
(g,b_inv) - the pair where: 
g - greatest common divisor of m and b. 
m_inv - is None if G is not of degree 0, 


and otherwise it is the polynomial such 
that b(X)*b_inv(X) = 1 mod m(X) 


mun 


degm = m.degree() ; 
degb = b.degree(); 


if(degb < 0) or (degm < degb): 
raise ValueError, "expected 0 <= degree(b) <= 
degree (m)" 


(Al, A2, A3) = (1, 0, m); 
(B1, B2, B3) = (0, 1, b); 


while (True): 


if (0 == B3): 
return (A3, None); 


if (0 == B3.degree()): 
return (B3/B3, B2/B3); 


Q = A3.quo_rem(B3) [0]; 


(T1, T2, T3) = (Al - Q*B1, A2 - Q*B2, AZB - Q*B3); 
(Al, A2, A3) = (B 1 B2, B3); 
(B1, B2, B3) = (T1, T2, 73); 


Example 5: Sage has built in functionality for the gcd function. The regular 
greatest common divisor function can simply be called as: 


sage: gcd(15,100) 
5 


sage: gcd(90,65311) 
1 


You can also call it as a method on Integer objects: 


sage: x = 10456890 
sage: x.gcd(100) 
10 


The extended Euclidean algorithm for the greatest common divisor is also 
built into Sage. Calling xgcd(a,b) returns a tuple, the first element is the gcd, 
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the 


second and third elements are coefficients u,v such _ that 


gcd(a,b) = u* a + v* b. This can be called as: 


sage: xgcd(17,31) 
(1, 11, -6) 

sage: xgcd(10, 115) 
(5, -11, 1) 


This can also be called as a method on Integer objects 


sage: x = 300 
sage: x.xgcd(36) 
(12, 1, -8) 


Example 6: Sage includes robust support for working with finite fields and 
performing finite field arithmetic. To initialize a finite field with prime order, 
use the GF command passing the order as the parameter. 


sage: F = GF(2) 
sage: F 
Finite Field of size 2 


sage: = GF (37) 
sage: 


Finite Field of size 37 


F 
F 


sage: p = 95131 

sage: K = GF(p) 

sage: K 

Finite Field of size 95131 


To initialize a field with a prime power order use the GF command with the 


following syntax (to keep track of the primitive element of the extension field.) 


sage: F.<a> = GF(128) 
sage: F 
Finite Field ina of size 2%7 


To do arithmetic in finite fields use the following syntax: 


sage: K = GF(37) 


sage: a = K(3) 
sage: b = K(18) 
sage: a - b 

22 

sage: a+b 

21 

sage: a * b 

17 

sage: a/b 


31 
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sage: a®-1 
25 
sage: l/a 
25 


To do arithmetic in a finite field with a prime power order, specify ele- 
ments using the primitive element: 


sage: F.<a> = GF(128) 
sage: b = a%2 +1 


sage: c = a%5 + a%3 +1 
sage: b-c 

a®5 a%®3 a®2 
sage: b+c 

a®5 a®3 a®2 
sage: b*c 

a®3 ar2 a 

sage: b/c 

a®5 a®3 a’2+a 
sage: b%*-1 

a®5 a®3 a 

sage: 1/b 

a®5 a®3 a 


Example 7: With Sage you can create rings of polynomials over finite fields 
and do arithmetic with them. To create polynomial rings over finite fields do 
the following: 


sage: R.<x> = GF(2) [] 
sage: R 


Univariate Polynomial Ring in x over Finite Field of 
size 2 (using NTL) 
sage: R.<x> = GF(101) [] 


sage: R 
sage: R.<x> = F[] 
sage: R 


Univariate Polynomial Ring in x over Finite Field in 
a of size 2°7 


After initializing a polynomial ring, you can then just perform arithmetic 
as you would expect: 


2) 


sage: R.<x> = GF( 
sage: f = x*3 + x 
sage: g = x*5 +x 
sage: f+g 

x5 x*3 i 
sage: f*g 
x8 x*6 x*5 + x*4 + x*2 + x 


)C] 
+ 1 
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Division is accomplished by the quo_rem function: 


sage: g.quo_rem(f) 
(x*2 + 1, x*2 + 1) 


You can also compute the greatest common divisor: 


sage: f.gcd(g) 


ME 

sage: g.gcd(g%*2) 

KAD + OX 

sage: R.<x> = GF(17) [] 
sage: f£ = 3*x*3 + 2*x*2 + x 
sage: g = x*2 + 5 

sage: f -g 

3*x*3 + x*2 +x + 12 


sage: f *g 

3*x*5 + 2*x°4 + 16*x*3 + 10*x*%2 + 5*x 
sage: £.quo_rem(g) 

(3*x + 2, 3*x + 7) 


And computing gcds in this polynomial ring we see: 


sage: f.gcd(g) 
HE 


sage: f.gcd(x*2 + x) 
x 


When creating a Sage finite field with a prime power order, Sage finds an irre- 
ducible polynomial for you. For example: 


sage: F.<a> = GF(32) 
a*5 + a%2 + 1 


However, there are many irreducible polynomials over GF(2) of degree 5, 
such as x5 + x3 + 1. Suppose that you want to create your own extension 
of the binary field with degree 5, and an irreducible polynomial of your choice. 
Then you can do so as follows: 


sage: R.<x> = GF(2) [] 
sage: F = GF(2).extension(x*5 + x*3 + 1, '‘a') 
sage: a = F.gen() 


You need to do this last step to inject the primitive element into the in- 
terpreter’s name space. This is done automatically when using the GF func- 
tion to create an extension field, but not when you use the member function 
extension on a field object. 
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B.5 CHAPTER 5: ADVANCED ENCRYPTION STANDARD 
Example 1: Simplified AES. 


# 
# These structures are the underlying 

# Galois Field and corresponding Vector Space 

# of the field used in the SAES algorithm 

# These structures allow us to easily compute with these fields. 
# 

F 

L 

V 


= GF(2); 

.<a> = GF(2%4); 

= L.vector_space(); 
VF8 = VectorSpace(F, 8); 


The MixColumns and its Inverse matrices are stored 

as 2x2 matrices with elements in GF(2*4) (as are state matrices.) 
The MixColumns operation (and its inverse) are performed by 
matrix multiplication. 


Se SE HE HEHE HE 


MixColumns_matrix = Matrix(L, [[1,a%2],[a%*2,1]]); 


InverseMixColumns_matrix = MixColumns_matrix.inverse(); 


SBox_matrix = Matrix(L, 


1+ a%3, a2, a +a*3, 1+ a+ a%3], 
1+ a*%2 + a%3, dy a 3s 1 + a%*2], 
a+ a2, 0, a, 1+ al, 
[ a*“2 + a%3, a+ a%2 + a%3, 1 + at ar%2 + a%3, 1+ a+ ar2i 
1); 
InverseSBox_matrix = Matrix(L, 
a+. a3, 1 + a%2, 1 + a%3, 1+a+t+a%3], 
1, 1 +a+t+a%2, a®3, 1 +a+ta%2 + a3], 
a+ a%2, OF a, 1 +al, 
[ a*%2 + a%3, ae2a, 1+ a®2 + a%3, a+a%*2 + a%3] 
1); 


RCON = [ 
VF8([F(0), F(0), F(0), F(0), F(0), F(0), F(0), F(1)]), 
VF8([F(0), F(0), F(0), F(0), F(1), F(1), F(0), F(0)]) 


674 APPENDIX B / SAGE EXAMPLES 


def SAES_ ToStateMatrix (block) : 
yuen 
Converts a bit list into an SAES state matrix. 


nun 


B = block; 


# form the plaintext block into a matrix of GF(2%*n) 


elements 

SOO = L(V([B[0O], B[1], B[2], B[3]])); 

S01 = L(V([B[4], B[5], B[6], B[7]])); 

S10 = L(V([B[8], B[9], B[10], B[11]])); 

S11 = L(V([B[12], B[13], B[14], B[15]])); 
state_matrix = Matrix(L, [[S00,S01],[S10,S11]]); 


return state_matrix; 


def SAES_ FromStateMatrix(State Matrix): 
yuen 
Converts an SAES State Matrix to a bit list. 


nun 


output = []; 


# convert State Matrix back into bit list 
for r in xrange(2): 
for c in xrange(2): 
v = V(State Matrix[r,c]); 
for j in xrange(4): 
output.append(Integer(v[j])); 


return output; 


def SAES_AddRoundKey(state_matrix, K): 
pun 
Adds a round key to an SAES state matrix. 


nun 


K_matrix = SAES_ ToStateMatrix(K); 
next_state_matrix = K_matrix + state matrix; 
return next_state_matrix; 


def SAES_MixColumns(state_matrix): 
pun 
Performs the Mix Columns operation. 
next_state_matrix = MixColumns_matrix*state_matrix; 
return next_state_matrix; 
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def SAES_InverseMixColumns (state_matrix): 
yuen 


Performs the Inverse Mix Columns operation. 
wen 

next_state_matrix = InverseMixColumns_matrix* 
state_matrix; 

return next_state_matrix; 


def SAES_ShiftRow(state_matrix): 

yuen 

Performs the Shift Row operation. 

M = state_matrix; 

next_state_matrix = Matrix(L, [ 
[M[0,0], M[0,1]], 
[M[1,1], M[1,0]] 
]); 


return next_state_matrix; 


def SAES_SBox(nibble): 
pun 
Performs the SAES SBox look up in the SBox matrix 
(lookup table.) 


nun 


v = nibble._vector_(); 


c = Integer(v[0]) + 2*Integer(v[1]); 
r = Integer(v[2]) + 2*Integer(v[3]); 
return SBox_matrix[r,c]; 


def SAES_ NibbleSubstitution(state_matrix): 
iG wow 
Performs the SAES SBox on each element of an SAES state 
matrix. 


mun 


M = state_matrix; 
next_state_matrix = Matrix(L, 
[ [ SAES_SBox(M[0,0]), SAES_SBox(M[0,1])], 
[ SAES_ SBox(M[1,0]), SAES_SBox(M[1,1])] ]); 
return next_state_matrix; 


def SAES_InvSBox (nibble): 
yuen 
Performs the SAES Inverse SBox look up in the SBox 
matrix (lookup table.) 


nun 


v = nibble._vector_(); 
c = Integer(v[0]) + 2*Integer(v[1]); 
r = Integer(v[2]) + 2*Integer(v[3]); 


return InverseSBox_matrix[r,c]; 
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def SAES_ InvNibbleSub(state_matrix) : 
pun 
Performs the SAES Inverse SBox on each element of an 
SAES state matrix. 


nun 


M = state_matrix; 
next_state_matrix = Matrix(L, 
[ [ SAES_InvSBox(M[0,0]), SAES_ InvSBox(M[0,1])], 
[ SAES_InvSBox(M[1,0]), SAES_InvSBox(M[1,1])] ]); 
return next_state_matrix; 


def RotNib(w): 
£¢ wow 
Splits an 8 bit list into two elements of GF(2%4) 


mun 


N_O = L(V([wlj] for j in xrange(4)])); 
N_1 = L(V([wI[j] for j in xrange(4,8)])); 
return (N_1, N_O); 


def SAES_g(w, i): 
ruen 
Performs the SAES g function on the 8 bit list w. 


nun 


(NO, N1) = RotNib(w); 

NO = V(SAES_SBox(NO)); 

N1 = V(SAES_SBox(N1)); 

templ = VF8( [ NO[0], NO[1], NO[2], NO[3], 
N1[0], N1[1], N1[2], N1[3] ] ); 


output = templ + RCON[i]; 
return output; 


def SAES KeyExpansion(K) : 
re wom 
Expands an SAES key into two round keys. 


mun 


w0O = VF8([K[j] for j in xrange(8)]); 
wl = VF8([K[j] for j in xrange(8,16)]); 


w2 = wO + SAES_g(wl, 0); 
w3 = wl + w2; 


w4 = w2 + SAES_g(w3, 1); 
w5 = w3 + w4; 


a 
lo) 
ll 


[wO[j] for j in xrange(8)]; 
KO.extend([wl[j] for j in xrange(8)]); 


Kil = [w2[j] for j in xrange(8)]; 
Kl.extend([w3[j] for j in xrange(8)]); 
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K2 = [w4[j3] for j in xrange(8)]; 
K2.extend([{w4[j] for j in xrange(8)]); 


return (KO, Kl, K2); 


# 

# Encrypts one plaintext block with key K 

# 

def SAES_ Encrypt (plaintext, K): 
ic: woo 
Performs a SAES encryption on a single plaintext 
block. 
(Both block and key passed as bit lists.) 
# get the key schedule 
(KO, Kl, K2) = SAES KeyExpansion(K) ; 
state_matrix0 = SAES_ToStateMatrix(plaintext) ; 
state_matrixl = SAES_AddRoundKey(state_matrix0, KO); 
state_matrix2 = SAES NibbleSubstitution 
(state_matrix1); 
state_matrix3 = SAES_ ShiftRow(state_matrix2); 
state_matrix4 = SAES_MixColumns(state_matrix3) ; 
state_matrix5 = SAES AddRoundKey(state_matrix4, K1); 
state_matrix6 = SAES NibbleSubstitution 
(state_matrix5); 
state_matrix7 = SAES_ShiftRow(state_matrix6) ; 
state_matrix8 = SAES_AddRoundKey(state_matrix7, K2); 
output = SAES FromStateMatrix(state_matrix8) ; 
return output; 

# 


# Decrypts one ciphertext block with key K 

# 

def SAES Decrypt (ciphertext, K): 
yuen 
Performs a single SAES decryption operation ona 
ciphertext block. 

(Both block and key passed as bit lists.) 


mun 


# perform key expansion 
(KO, Kl, K2) = SAES_ KeyExpansion(K) ; 
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# form the ciphertext block into a matrix of GF(2%*n) 
elements 


state_matrix0 SAES_ToStateMatrix(ciphertext) ; 


state_matrixl SAES_AddRoundKey (state_matrix0, K2); 
state_matrix2 = SAES_ ShiftRow(state_matrixl1) ; 
state_matrix3 = SAES_InvNibbleSub(state_matrix2) ; 


state_matrix4 = SAES_AddRoundKey(state_matrix3, K1); 


Il 


state_matrix5 SAES_InverseMixColumns 
(state_matrix4) ; 


state_matrix6 = SAES ShiftRow(state_matrix5); 


state_matrix7 = SAES InvNibbleSub(state_matrix6) ; 


state_matrix8 SAES_AddRoundKey (state_matrix7, KO); 
output = SAES FromStateMatrix(state_matrixs) ; 


return output; 


B.6 CHAPTER 6: PPEUDORANDOM NUMBER GENERATION 


AND STREAM CIPHERS 


Example 1: Blum Blum Shub RNG 


def BlumBlumShub_Initialize(bitlen, seed): 
rt nono 
Initializes a Blum-Blum-Shub RNG State. 


A BBS-RNG State is a list with two elements: 
IN, X] 

N is a 2*bitlen modulus (product of two primes) 
X is the current state of the PRNG. 


INPUT: 


bitlen - the bit length of each of the prime 
factors of n 


seed - a large random integer to start out the prng 
OUTPUT: 
state - a BBS-RNG internal state 


# note that this is not the most cryptographically 
secure 
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def 


# way to generate primes, because we do not know how the 
# internal sage random_prime function works. 


p = 3; 

while (p < 2*%(bitlen-1)) or (3 != (p % 4)) 
p = random_prime(2*bitlen) ; 

q = 3; 

while (q < 2*%(bitlen-1)) or (3 != (q % 4)) 
q = random_prime(2*bitlen); 

N = p*q; 

X = (seed*2 % N) 

state = [N, X] 

return state; 

BlumBlumShub_Generate(num_bits, state): 


tC momo 
Blum-Blum-Shum random number generation function. 


INPUT: 
num_bits - the number of bits (iterations) to 
generate with this RNG. 
state - an internal state of the BBS-RNG (a 
list [N, X].) 

OUTPUT: 


random_bits - a num_bits length list of random 


bits. 


nun 


[]; 


random_bits = 


N = state[0] 
X = state[1] 
for j in xrange(num_bits): 


X = X°.2 3N 
random_bits.append(X % 2) 


# update the internal state 
state[1] = X; 


return random_bits; 


Example 2: Linear Congruential RNG 


def LinearCongruential_Initialize(a, 


Gyn Ol) 
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r nomow 
This functional initializes a linear congruential 
RNG state. 


This state is a list of four integers: [a, c, m, X] 


a,c,m are the parameters of the linear congruential 
instantiation X is the current state of the PRNG. 


INPUT: 


a - The coefficient 

c - The offset 

m - The modulus 

XO - The initial state 


OUTPUT: 
state - The initial internal state of the RNG 
return [a,c,m,X0] 


def LinearCongruential_Generate(state): 
Hg now 
Generates a single linear congruential RNG output 
and updates the state. 


INPUT: 
state - an internal RNG state. 
OUTPUT: 


X - a single output of the linear congruential 
RNG. 


= state[0] 
= state[1] 

state[2] 
= state[3] 
_next = (a*X + c) @m 
state[3] = X_next 
return X_next 
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Example 1: Chinese Remainder Theorem. 


xrxM BAM 
Il 


def chinese _remainder_theorem(moduli, residues): 
r nom 
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Function that implements the chines remainder 
theorem. 
INPUT: 

moduli - list or positive integers. 

residues - list of remainders such that remainder 


at position j results when divided by the corresponding 
modulus at position j in moduli. 


OUTPUT: 


x - integer such that division by moduli[j] gives 
remainder residue[j]. 


nun 


if (len(moduli) != len(residues)): 


raise ValueError, "expected len (moduli) == 
len (residues) " 


M = prod(moduli) ; 
x= 03 


for j in xrange(len(moduli) ): 
Mj = modulilj] 
Mpr = M/Mj 


(Mj_Mpr_gced, Mpr_inv, Mj_inv) = xgcd(Mpr, Mj) 
Mpr_inv = Mpr_inv 


if (Mj_Mpr_gcd != 1): 


raise ValueError, "Expected all moduli are 
coprime." 


x += residues[j]*Mpr*Mpr_inv; 


return xX; 


Example 2: Miller Rabin Primality Test. 


run 
EXAMPLES: 


sage: MILLER_RABIN_TEST(101) 
False 


sage: MILLER_RABIN TEST (592701729979) 
True 


nun 
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def MILLER_RABIN_TEST(n) : 


wun 
re 


This function implements the Miller-Rabin Test. 
It either returns "inconclusive" or "composite." 


INPUT: 


n - positive integer to probabilistically deter- 
mine the primality of. 


OUTPUT: 


If the function returns False, then the test was 
inconclusive. 


Tf the function returns True, then the test was 
conclusive and n is composite. 


nun 


R = IntegerModRing(n); # object for integers mod n 
# (1) Find integers k, q w/ k > 0 and q odd so that 
(n-1) == 2*%k * q 
q=n-l 
k = 0 
while (1 == (q % 2)): 
k += 1 
q = q.quo_rem(2) [0] # q/2 but with result of type 
Integer 


# (2) select random a in 1~<a< n-1l 
a = randint(1,n-1) 
a = R(a) # makes it so modular exponentiation is 


done fast 


# if a*q mod n == 1 then return inconclusive 
if (1 == a%q): 
return False 


# (3) for j = 0 to k-1 do: if a*(2*j * q) mod n = 
n-1 return inconclusive 


e=q 

for j in xrange(k): 
if (n-1) == (a%e): 
return False 
e = 2*e 


# (4) if you’ve made it here return composite. 
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return True 


Example 3: Modular Exponentiation (Square and Multiply). 


def ModExp(x,e,N): 
rc mono 


Calculates x*e mod N using square and multiply. 


INPUT: 


x - an integer. 
e€ - a nonnegative integer. 
N - a positive integer modulus. 


OUTPUT: 


y - x*e mod N 


nun 


e_bits = e.bits() 
e_bitlen = len(e_bits) 


ye=l 


for j in xrange(e_bitlen): 


if (1 == e_bits[e_bitlen-1-j]): 
y= x*y 3N 
return y 


Example 4: Using built-in Sage functionality for CRT. 

Sage has built in functions to perform the Chinese Remainder Theorem. 
There are several functions that produce a wide array of CRT functionality. 
The simplest function performs the CRT with two modulii. Specifically CRT 
(or the lowercase crt) when called as: 


ert(a,b,m,n) 


will return a number that is simultaneously congruent to a mod mand b mod 
n. All parameters are assumed to be Integers and the parameters m, n must be 
relatively prime. Some examples of this function are: 


sage: CRT(8, 16, 17, 49) 
-3120 
sage: CRT(1,2,5,7) 
16 


sage: CRT(50,64,101,127) 
-62166 


If you want to perform the CRT with a list of residues and moduli, Sage 
includes the function CRT_list. 
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CRT_list(v, modulii) 


requires that v and modulii be lists of Integers of the same length. Further- 
more, the elements of modulii must be relatively prime. Then the output is an 
integer that reduces to v[i] mod modulii[i] (for i in range(len(v))). For exam- 
ple, the last call to CRT would have been 


sage: CRT_list([50,64],[101,127]) 
1969 


Note that this answer is different. However, you can check that both answers 
satisfy the requirements of the CRT. Here are examples with longer lists: 


sage: CRT_list([8, 20, 13], [49, 101, 127]) 
608343 


sage: CRT_list([10,11,12,13,14], [29,31,37,41,43]) 
36657170 


The function CRT_basis can be used to precompute the values associated to 
the given set of modulii. If modulii is a list of relatively prime modulii, then 
CRT_basis(modulii) returns a list a. This list a is such that if x is a list of 
residues of the modulii, then the output of the CRT can be found by summing: 


a[O]*x[0O] + a[1]*x[1] + ... + a[len(a)-1]*x[len(a)-1] 


In the case of the modulii used in the last call to CRT_list this function returns 
as follows: 


sage: CRT_basis([29,31,37,41,43]) 
[32354576, 20808689, 23774055, 17163708, 23184311] 


The last CRT function that Sage provides is CRT_vectors. This function per- 
forms CRT_list on several different lists (with the same set of modulii) and re- 
turns a list of the simultaneous answers. It is efficient in that it uses CRT_basis 
and does not recompute those values for each list. For example: 


sage: 
CRT vectors ([ [1,10], [2711]; [3,22]. (4,13), 15,1411, 
[29.31, 37, 41,43 ])) 


[36657161, 36657170] 


Example 5: Using built-in Sage functionality for Modular Exponentiation. 

Sage can perform modular exponentiation using fast algorithms (like 
square and multiply) and without allowing the intermediate computations to 
become huge. This is done through IntegerModRing objects. Specifically, 
creating an IntegerModRing object indicates that arithmetic should be done 
with a modulus. Then you cast your integers in this ring to indicate that all 
arithmetic should be done with the modulus. Then for elements of this ring, ex- 
ponentiation is done efficiently. For example: 


sage: R = IntegerModRing (101) 


sage: x = 
sage: x*%9 
91 

sage: R= 
sage: x = 
sage: x%*3 
751 

sage: x = 
sage: x%*%2 
0 

sage: N 
sage: R= 
sage: x = 
sage: x*%9 
9177 
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IntegerModRing (1024) 
R(111) 
45 


R(100) 
00 


= 127*101 
= IntegerModRing (N) 


R(54) 
5 


Creating an IntegerModRing is similar to creating a FiniteField with GF(...) 
except that the modulus can be a general composite. 


Example 6: Using 


built-in Sage functionality for Euler’s totient. 


Sage has the Euler totient functionality built in. The function is called 


euler_phi because 


of the convention of using the Greek letter phi to represent 


this function. The operation of this function is simple. Just call euler_phi on an 
integer and it computes the totient function. This function factors the input, 
and hence requires exponential time. 


er_phi(101) 


er_phi (1024) 


sage: eul 
100 
sage: eul 
512 
sage: eul 
216 
sage: eul 
100 
sage: eul 
276 


er_phi (333) 


er_phi (125) 


er_phi (423) 
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Example 1: Using Sage we can simulate an RSA encryption and decryption. 


sage: # randomly select some prime numbers 


sage: p = 
1:9). 


random_prime(1000); p 
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sage: q = random_prime(1000); q 

601 

sage: # compute the modulus 

sage: N = p*qg 

sage: R = IntegerModRing (N) 

sage: phi_N = (p-1)*(q-1) 

sage: # we can choose the encrypt key to be anything 
sage: # relatively prime to phi_N 


sage: e = 17 
sage: gcd(d, phi_N) 
al. 


sage: # the decrypt key is the multiplicative inverse 
sage: # of d mod phi_N 

sage: d = xgcd(d, phi_N)[1] % phi_N 

sage: d 

60353 

sage: # Now we will encrypt/decrypt some random 7 
digit numbers 


sage: P = randint(1,127); P 
97 

sage: # encrypt 

sage: C = R(P)%*e; C 

46685 

sage: # decrypt 

sage: R(C)%*d 

97 


sage: P = randint(1,127); P 
46 

sage: # encrypt 

sage: C = R(P)%*e; C 

75843 

sage: # decrypt 

sage: R(C)%*d 

46 


sage: P = randint(1,127); P 
3 

sage: # encrypt 

sage: C = R(P)%*e; C 

288 

sage: # decrypt 

sage: R(C)*d 

3 


Also, Sage can just as easily do much larger numbers: 


sage: p = random_prime(1000000000); p 
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114750751 

sage: q = random_prime(1000000000); q 
8916569 

sage: N = p*qg 

sage: R = IntegerModRing (N) 


sage: phi_N = (p-1)*(q-1) 
sage: e = 2°16 +1 
sage: d = xgcd(e, phi_N) [1] % phi_N 
sage: d 

237150735093473 


sage: P = randint(1,1000000); P 
955802 

sage: C = R(P)%*e 

sage: R(C)*d 

955802 


Example 2: In Sage, we can also see an example of RSA signing/verifying. 


sage: p = random_prime(10000); p 
1601 

sage: q = random_prime(10000); q 
4073 

sage: N = p*qg 

sage: R = IntegerModRing (N) 
sage: phi_N = (p-1)*(q-1) 

sage: e = 47 

sage: gcd(e, phi_N) 

1 

sage: d = xgcd(e,phi_N) [1] % phi_N 


sage: # Now by exponentiating with the private key 
sage: # we are effectively signing the data 
sage: # a few examples of this 


sage: to_sign = randint(2,2%°10); to_sign 

650 

sage: # the signature is checked by exponentiating 
sage: # and checking vs the to_sign value 

sage: signed = R(to_sign)*d; signed 


2910116 

sage: to_sign == signed*’e 

True 

sage: to_sign = randint(2,2%°10); to_sign 
362 

sage: Signed = R(to_sign)*d; signed 
546132 

sage: to_sign == signed%e 


True 
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sage: # we can also see what happens if we try to 
verify a bad signature 


sage: to_sign = randint(2,2%°10); to_sign 


605 

sage: signed = R(to_sign)*d; signed 

1967793 

sage: bad_signature = signed - randint(2,100) 
sage: to_sign == bad_signature%’e 

False 


B.9 CHAPTER 10: OTHER PUBLIC-KEY CRYPTOSYSTEMS 


Example 1: Here is an example of Alice and Bob performing a Diffie-Hellman 


Key Exchange done in Sage: 
sage: # Alice and Bob agree on the domain parameters: 
sage: p = 619 
sage: F = GF(p) 
sage: g = F(2) 
sage: # Alice picks a random value x in 1...618 
sage: x = randint(1,618); x 
571 
sage: # Alice computes X = g*x and sends this to Bob 
sage: X = g*571; X 
591 
sage: # Bob picks a random value y in 1...618 
sage: y = randint(1,618);y 
356 


sage: # Bob computes Y = g*y and sends this to Alice 
sage: Y = g*y; Y 

199 

sage: # Alice computes Y*x 

sage: Y*x 


563 

sage: # Bob computes X*y 
sage: X*y 

563 


sage: # Alice and Bob now share a secret value 


Example 2: In reality to prevent what is known as small subgroup attacks, 
the prime p is chosen so that p — 2q + 1 where p is a prime as well. 


sage: q = 761 
sage: p = 2*qi1 
sage: is_prime(q) 
True 
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sage: is_prime(p) 
True 

sage: F = GF( 
sage: g = F(3 


SG 


sage: g*q 

HE 

sage: # note that g*q = 1 implies g is of order q 
sage: # Alice picks a random value x in 2...q-1 
sage: x = randint(2,q-1); x 

312 

sage: # Alice computes X = g*x and sends it to Bob 


sage: X = g*x; X 


26 

sage: # Bob computes a random value y in 2...q-1 
sage: y = randint(2,q-1); y 

24 

sage: Bob computes Y = g*y and sends it to Alice 


# 
sage: Y = g*y; Y 
1304 
sage: # Alice computes Y%*x 
sage: Y*x 


541 

sage: # Bob computes X%“*y 
sage: X“y 

541 


sage: # Alice and Bob now share the secret value 541 


Example 3: Sage has a significant amount of support for elliptic curves. This 
functionality can be very useful when learning, because it allows you to 
easily calculate things and get the big picture. Doing the examples by hand 
may cause you to get mired in the details. First you instantiate an elliptic 
curve, by specifying the field that it is over, and the coefficients of the 
defining Weierstrass equation. For this purpose, we write the Weierstrass 
equation as 


yo + ayxy 4 ay=x t ox" F 4x + Ag 


Then the Sage function EllipticCurve(R, [al, a2, a3, a4, a6]) creates the elliptic 
curve over the ring R. 


sage: E = EllipticCurve(GF(17), [1,2,3,4,5]) 

sage: E 

Elliptic Curve defined by y*2 + x*y + 3*y = x*3 + 
2*x*2 + A*x + 5 over Finite Field of size 17 


sage: E = EllipticCurve(GF(29), [0,0,0,1,1]) 
sage: E 
Elliptic Curve defined by y*2 = x*3 + x + 1 over 


Finite Field of size 29 


690 
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sage: E = EllipticCurve(GF(127), [0,0,0,2,17]) 

sage: E 

Elliptic Curve defined by y*2 = x*3 + 2*x + 17 over 
Finite Field of size 127 


sage: F.<theta> = GF(2%10) 

sage: E = EllipticCurve(F, [1,0,0,1,0]) 

sage: E 

Elliptic Curve defined by y*2 + x*y = x*3 + x over 
Finite Field in theta of size 2°10 


Example 4: Koblitz curves. A Koblitz curve is an elliptic curve over a binary 
field defined by an equation of the form 


ytxuy=xe+ar4+1 


where a = 0 or 1. FIPS 186-3 recommends a number of Koblitz curves for use 
with the Digital Signature Standard (DSS). Here we give an example of a 
curve of similar form to the Koblitz curves: 


sage: F.<theta> = GF(2%17) 

sage: E = EllipticCurve(F,[1,0,0,theta,1]) 

sage: E 

Elliptic Curve defined by y*2 + y = x*3 + theta* x*2 = 1 
over Finite Field in theta of size 2°17 


Example 5: Sage can even easily instantiate curves of cryptographic sizes, like 
K163, which is one of the FIPS 186-3 curves. 


sage: F.<theta> = GF(2%163) 

sage: E = EllipticCurve(F, [1,0,0,1,1]) 

sage: E 

Elliptic Curve defined by y*2 + x*y = x*3 + x*2 + 1 
over Finite Field in theta of size 2%*163 


However, you should be careful that when instantiating a curve of crypto- 
graphic sizes, some of the functions on the curve object will not work because 
they require exponential time to run. While you can compute some things with 
these objects, it is best to leave your experimentation to the smaller sized 
curves. 

You can calculate some values of the curve, such as the number of points: 


sage: E = EllipticCurve(GF(107), [0,0,0,1,0]) 
sage: E.order() 
108 


You can also determine the generators of a curve: 


sage: E = EllipticCurve(GF(101), [0,0,0,1,0]) 
sage: E.gens() 
CC? #42) 4. 1), (36: + 38 = 2)) 
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Note that this output is printed (x : y: z). This is a minor technical consideration 
because Sage stores points in what is known as “projective coordinates.” The 
precise meaning is not important, because for non-infinite points the value z will 
always be 1 and the first two values in a coordinate will be the x and y coordi- 
nates, exactly as you would expect. This representation is useful because it allows 
the point at infinity to be specified as a point with the z coordinate equal to 0: 


sage: E(0) 
(O.. = “2. = 0) 


This shows how you can recognize a point at infinity as well as specify it. If you 
want to get the x and y coordinates out of a point on the curve, you can do so 
as follows: 


sage: P = E.random_point(); P 
(62 : 38 : 1) 

sage: (x,y) = P.xy(); (x,y) 
(62, 38) 


You can specify a point on the curve by casting an ordered pair to the curve as: 
((62,-38)); P 
(62 3 63: 2 1) 


Now that you can find the generators on a curve and specify points you can 
experiment with these points and do arithmetic as well. Continuing to use E as 
the curve instantiated in the previous example, we can set G1 and G2 to the 
generators: 


sage: (Gl, G2) = E.gens() 
sage: P = E.random_point(); P 
(49° 29: ~ 21.) 


You can compute the sum of two points as in the following examples: 


sage: Gl + G2 +P 
(69 2 96 2 21) 
sage: Gl +P 

(40 : 62 : 1) 
sage: P + P + G2 
(84 : 25 : 1) 


You can compute the inverse of a point using the unary minus (—) operator: 


sage: -P 
(49 : 72 : 1) 
sage: -Gl 
(7 = 59 = -1) 


You can also compute repeated point addition (adding a point to itself many 
times) with the * operator: 


sage: 13*G1 
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(72 
sage: 
(9 
sage: 
(87 


23 = 1) 
2*G2 


58 : 1) 


88*P 
75% J) 


And for curves over small finite fields you can also compute the order 
(discrete log of the point at infinity with respect to that point). 


sage: 
10 


sage: 
10 


sage: 
10 


G1.order () 


G2 .order () 


P.order () 


Example 6: Using the Sage elliptic curve functionality to perform a simulated 
elliptic curve Diffie-Hellman (ECDH) key exchange. 


sage: # calculate domain parameters 

sage: F = GF(127) 

sage: E = EllipticCurve(F, [0, 0, 0, 3, 4]) 
sage: G = E.gen(0); G 

(94 6 1) 

sage: q = E.order(); q 

122 

sage: # Alice computes a secret value x in 2... 
q-1 

sage: x = randint(2,q-1); x 

33 

sage: # Alice computes a public value X = x*G 
sage: X = x*G; X 

(55 89 : 1) 

sage: # Bob computes a secret value y in 2...q-1 
sage: y = randint(2,q-1); y 

55 

sage: # Bob computes a public value Y = y*G 
sage: Y = y*G; Y 

(84 39 : 1) 

sage: # Alice computes the shared value 

sage: x*Y 

(91 105 : 1) 

sage: # Bob computes the shared value 

sage: y*X 

(91 105 : 1) 
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However, in practice most curves that are used have a prime order: 


sage: # Calculate the domain parameters 

sage: F = GF(101) 

sage: E = EllipticCurve(F, [0, 0, 0, 25, 7]) 
sage: G = E((97,34)) 

sage: q = E.order() 

sage: # Alice computes a secret values x in 2...q-1 
sage: x = randint(2,q-1) 

sage: # Alice computes a public value X = x*G 
sage: X = x*G 

sage: # Bob computes a secret value y in 2...q-1 
sage: y = randint(2,q-1) 

sage: # Bob computes a public value Y = y*G 
sage: Y = y*G 

sage: # Alice computes the shared secret value 
sage: x*Y 

(23.43. TE5 5 = ) 

sage: # Bob computes the shared secret value 
sage: y*X 

(23-3 125-2 ) 
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Example 1: The following is an example of the MASH hash function in 
Sage. MASH is a function based on the use of modular arithmetic. It involves 
use of an RSA-like modulus M, whose bit length affects the security. 
M should be difficult to factor, and for M of unknown factorization, the 
security is based in part on the difficulty of extracting modular roots. M also 
determines the block size for processing messages. In essence, MASH is 


defined as: 
H, = ((x; ® H;_-;)"OR H;_;) (mod M) 
where 
A = 0xFFO0...00 


H,_, = the largest prime less than M 


x; = the ith digit of the base M expansion of input n. That is, we express n 
as a number of base M. Thus: 


n=X) +x%4M+xM 4 


The following is an example of the MASH hash function in Sage 


# 

# This function generates a mash modulus 
# takes a bit length, and returns a Mash 
# modulus 1 or 1-1 bits long (if n is odd) 
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# returns p, q, and the product N 


# 
def generate_mash_modulus(1): 
m = 1.quo_rem(2) [0] 
pet 
while (p < 2%(m-1)): 
p = random_prime (2m) 
q=l 
while (q < 2%(m-1)): 
q = random_prime (2m) 
N = p*q 


return (N, p, q) 


Mash Hash 


the value N is the modulus 
Returns the hash value. 


Se SE HE OE HEE 


def MASH(n, N): 


H = previous_prime (N) 


qn 
while (0 != q): 

(q, a) = q.quo_rem(N) 
H = ((H+a)*2 + H) @N 


return H 


The output of these functions running; 


sage: data = ZZ(randint(1,2% 
sage: (N, p, q) = generate_m 
sage: MASH(data, N) 

220874 

sage: (N, p, q) = generate_m 
sage: MASH(data, N) 
455794413217080 

sage: (N, p, q) = generate_m 


sage: MASH(data, N) 
2688645045385085177546482850 
sage: data = ZZ(randint(1,2% 
sage: MASH(data, N) 
2368625810747368819192960712 


1000) ) 


ash_modul 


ash_modul 


the value n is the data to be hashed. 


us (20) 


us (50) 


ash_modul]l 


37 
1000) ) 


48 


lus (100) 
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sage: data = ZZ(randint(1,2%1000) ) 
sage: MASH(data, N) 
395463068716770866931052945515 
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Example 1: Using Sage, we can perform a DSA sign and verify: 


sage: # First we generate the domain parameters 
sage: # Generate a 16 bit prime q 
sage: q=1; 


sage: while (q < 2°15): q = random_prime(2%*16) 


sage: # Generate a 64 bit p, such that q divides (p-1) 
sage: p= 1 

sage: while (not is_prime(p)): 

..ee.t P= (2°48 + randint(1,2%46)*2)*q + 1 
sage: p 

12797003281321319017 

sage: # Generate h and g 

sage: h = randint(2,p-2) 

sage: h 

5751574539220326847 

sage: F = GF(p) 

sage: g = F(h)*((p-1)/q) 

sage: g 

9670562682258945855 


sage: # Generate a user public / private key 


sage: # private key 
sage: x = randint(2,q-1) 
sage: x 

20499 


sage: # public key 
sage: y = F(g)*x 
sage: y 
7955052828197610751 


sage: # Sign and verify a random value 
sage: H = randint(2,p-1) 


sage: # Signing 
sage: # random blinding value 
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sage: k = randint(2,q-1) 
sage: r = F(g)*k 3 q 

sage: r = F(g)*k 

sage: r = r.lift() *q 

sage: r 

6805 

sage: kinv = xgcd(k,q)[1] *q 
sage: s = kinv*(H + x*r) 3q 
sage: s 

26026 


sage: # Verifying 

sage: w = xgcd(s,q) [1]; w 
12250 

sage: ul = H*w % q; ul 
6694 
sage: u2 
16706 
sage: v = 
sage: 
sage: v 

6805 

sage: v == fr 
True 


ll 
K 
* 
= 
oo 
1 
(= 
ine) 


<j 
Wool 
< 4 
HQ 
H- ~ 
Fh > 
tc 
a~ RR 

* 
oe 

Hy 
iO = 


Sign and verify another random value 
= randint (2,p-1) 


sage: 
sage: 


randint (2,q-1) 
F(g)*k 
r.lift() %®q 


sage: 
sage: 
sage: 
sage: 
3284 
sage: kinv = xgcd(k,q)[1] *q 
sage: s = kinv*(H + x*r) %q 
sage: s 

2330 


RRR wt Ot oe 
Il 


sage: # Verifying 

sage: w = xgcd(s,q) [1]; w 
4343 

sage: ul = H*w % q; ul 
32191 
sage: u2 
1614 
sage: v = 
sage: 
sage: v 


ll 
K 
* 
= 
oo 
1Q 
c 
iN) 


< 
Wool 
< 4 
HQ 
H- ~ 
Fh > 
atc 
a~ RR 

* 
oe 

Hy 
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Example 2: The following functions implement DSA domain parameter gen- 
eration, key generation, and DSA Signing: 


# 


# Generates a 16 bit q and 64 bit p, both prime 
# such that q divides p-1 


# 
def 


g 


1 


while (1 


return 


# 


DSA_generate_domain_parameters(): 


== 2 


# first find aq 


ile (q < 2%15): q = random_prime(2%*16) 


# next find ap 


ile (not is_prime(p)): 


p = (2°47 + randint(1,2%45)*2)*q + 1 


= GF(p) 


F 
h = randint(2,p-1) 
g = (F(h)*((p-1)/q)).1i£t() 


(p, @, g) 


# Generates a users private and public key 
# given domain parameters p, q, andg 


# 
def 


+e HE HEHEHE HE 


DSA_generate_keypair(p, q, g): 
x = randint(2,q-1) 

F = GF(p) 

y = F(g)*x 

y = y.lift() 

return (x,y) 


Given domain parameters p, q and g 

as well as a secret key x 

and a hash value H 

this performs the DSA signing algorithm 
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def DSA_sign(p, q, g, x, H): 


k = randint(2,q-1) 


F = GF(p) 
r = F(g)*k 
r=r.lift() *q 


kinv = xgcd(k,q)[1] %q 
s = kinv*(H + x*r) %®q 
return (r, s) 
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They agreed that Graham should set the test for Charles Mabledene. It was nei- 
ther more nor less than that Dragon should get Stern’s code. If he had the ‘in’ at 
Utting which he claimed to have this should be possible, only loyalty to Moscow 
Centre would prevent it. If he got the key to the code he would prove his loyalty 
to London Central beyond a doubt. 


—Talking to Strange Men, Ruth Rendell 


KEY POINTS 


® Unauthorized intrusion into a computer system or network is one of the 
most serious threats to computer security. 


® Intrusion detection systems have been developed to provide early warning 
of an intrusion so that defensive action can be taken to prevent or mini- 
mize damage. 

® Intrusion detection involves detecting unusual patterns of activity or 
patterns of activity that are known to correlate with intrusions. 

® One important element of intrusion prevention is password management, 
with the goal of preventing unauthorized users from having access to the 
passwords of others. 


A significant security problem for networked systems is hostile, or at least 
unwanted, trespass by users or software. User trespass can take the form of unau- 
thorized logon to a machine or, in the case of an authorized user, acquisition of priv- 
ileges or performance of actions beyond those that have been authorized. Software 
trespass can take the form of a virus, worm, or Trojan horse. 

All these attacks relate to network security because system entry can be 
achieved by means of a network. However, these attacks are not confined to net- 
work-based attacks. A user with access to a local terminal may attempt trespass 
without using an intermediate network. A virus or Trojan horse may be introduced 
into a system by means of an optical disc. Only the worm is a uniquely network phe- 
nomenon. Thus, system trespass is an area in which the concerns of network security 
and computer security overlap. 

Because the focus of this book is network security, we do not attempt a com- 
prehensive analysis of either the attacks or the security countermeasures related 
to system trespass. Instead, in this Part we present a broad overview of these 
concerns. 

This chapter covers the subject of intruders. First, we examine the nature of 
the attack and then look at strategies intended for prevention and, failing that, 
detection. Next we examine the related topic of password management. 
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20.1 INTRUDERS 


One of the two most publicized threats to security is the intruder (the other is 
viruses), often referred to as a hacker or cracker. In an important early study of 
intrusion, Anderson [ANDE80] identified three classes of intruders: 


e Masquerader: An individual who is not authorized to use the computer and 
who penetrates a system’s access controls to exploit a legitimate user’s account 


e Misfeasor: A legitimate user who accesses data, programs, or resources for 
which such access is not authorized, or who is authorized for such access but 
misuses his or her privileges 

e Clandestine user: An individual who seizes supervisory control of the system 
and uses this control to evade auditing and access controls or to suppress audit 
collection 


The masquerader is likely to be an outsider; the misfeasor generally is an insider; 
and the clandestine user can be either an outsider or an insider. 

Intruder attacks range from the benign to the serious. At the benign end of the 
scale, there are many people who simply wish to explore internets and see what is 
out there. At the serious end are individuals who are attempting to read privileged 
data, perform unauthorized modifications to data, or disrupt the system. 

[GRAN04] lists the following examples of intrusion: 


e Performing a remote root compromise of an e-mail server 
e Defacing a Web server 

e Guessing and cracking passwords 

e Copying a database containing credit card numbers 


e Viewing sensitive data, including payroll records and medical information, 
without authorization 


e Running a packet sniffer on a workstation to capture usernames and pass- 
words 


e Using a permission error on an anonymous FTP server to distribute pirated 
software and music files 


e Dialing into an unsecured modem and gaining internal network access 


e Posing as an executive, calling the help desk, resetting the executive’s e-mail 
password, and learning the new password 


e Using an unattended, logged-in workstation without permission 


Intruder Behavior Patterns 


The techniques and behavior patterns of intruders are constantly shifting, to exploit 
newly discovered weaknesses and to evade detection and countermeasures. Even 
so, intruders typically follow one of a number of recognizable behavior patterns, and 
these patterns typically differ from those of ordinary users. In the following, we look 
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at three broad examples of intruder behavior patterns, to give the reader some feel 
for the challenge facing the security administrator. Table 20.1, based on [RADC04], 
summarizes the behavior. 


Hackers Traditionally, those who hack into computers do so for the thrill of it or 
for status. The hacking community is a strong meritocracy in which status is 
determined by level of competence. Thus, attackers often look for targets of 
opportunity and then share the information with others. A typical example is a 
break-in at a large financial institution reported in [RADC04]. The intruder took 
advantage of the fact that the corporate network was running unprotected services, 
some of which were not even needed. In this case, the key to the break-in was the 
pcAnywhere application. The manufacturer, Symantec, advertises this program as a 
remote control solution that enables secure connection to remote devices. But the 
attacker had an easy time gaining access to pcAnywhere; the administrator used the 
same three-letter username and password for the program. In this case, there was no 
intrusion detection system on the 700-node corporate network. The intruder was 
only discovered when a vice president walked into her office and saw the cursor 
moving files around on her Windows workstation. 


Table 20.1 Some Examples of Intruder Patterns of Behavior 
(a) Hacker 


. Select the target using IP lookup tools such as NSLookup, Dig, and others. 


. Map network for accessible services using tools such as NMAP. 

. Identify potentially vulnerable services (in this case, pcAnywhere). 
. Brute force (guess) pcAnywhere password. 

. Install remote administration tool called DameWare. 


. Wait for administrator to log on and capture his password. 


. Use that password to access remainder of network. 
(b) Criminal Enterprise 


. Act quickly and precisely to make their activities harder to detect. 

2. Exploit perimeter through vulnerable ports. 
. Use Trojan horses (hidden software) to leave back doors for reentry. 
. Use sniffers to capture passwords. 

5. Do not stick around until noticed. 


. Make few or no mistakes. 


(c) Internal Threat 


. Create network accounts for themselves and their friends. 
. Access accounts and applications they wouldn’t normally use for their daily jobs. 
. E-mail former and prospective employers. 


. Conduct furtive instant-messaging chats. 


. Visit Web sites that cater to disgruntled employees, such as f'dcompany.com. 


. Perform large downloads and file copying. 


. Access the network during off hours. 
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Benign intruders might be tolerable, although they do consume resources and 
may slow performance for legitimate users. However, there is no way in advance to 
know whether an intruder will be benign or malign. Consequently, even for systems 
with no particularly sensitive resources, there is a motivation to control this problem. 

Intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) 
are designed to counter this type of hacker threat. In addition to using such systems, 
organizations can consider restricting remote logons to specific IP addresses and/or 
use virtual private network technology. 

One of the results of the growing awareness of the intruder problem has been 
the establishment of a number of computer emergency response teams (CERTs). 
These cooperative ventures collect information about system vulnerabilities and 
disseminate it to systems managers. Hackers also routinely read CERT reports. 
Thus, it is important for system administrators to quickly insert all software patches 
to discovered vulnerabilities. Unfortunately, given the complexity of many IT 
systems, and the rate at which patches are released, this is increasingly difficult to 
achieve without automated updating. Even then, there are problems caused by 
incompatibilities resulting from the updated software. Hence the need for multiple 
layers of defense in managing security threats to IT systems. 


CRIMINALS Organized groups of hackers have become a widespread and common 
threat to Internet-based systems. These groups can be in the employ of a corpo- 
ration or government but often are loosely affiliated gangs of hackers. Typically, 
these gangs are young, often Eastern European, Russian, or southeast Asian 
hackers who do business on the Web [ANTE06]. They meet in underground forums 
with names like DarkMarket.org and theftservices.com to trade tips and data and 
coordinate attacks. A common target is a credit card file at an e-commerce server. 
Attackers attempt to gain root access. The card numbers are used by organized 
crime gangs to purchase expensive items and are then posted to carder sites, where 
others can access and use the account numbers; this obscures usage patterns and 
complicates investigation. 

Whereas traditional hackers look for targets of opportunity, criminal hackers 
usually have specific targets, or at least classes of targets in mind. Once a site is pene- 
trated, the attacker acts quickly, scooping up as much valuable information as possi- 
ble and exiting. 

IDSs and IPSs can also be used for these types of attackers, but may be less 
effective because of the quick in-and-out nature of the attack. For e-commerce 
sites, database encryption should be used for sensitive customer information, espe- 
cially credit cards. For hosted e-commerce sites (provided by an outsider service), 
the e-commerce organization should make use of a dedicated server (not used to 
support multiple customers) and closely monitor the provider’s security services. 


INSIDER ATTACKS Insider attacks are among the most difficult to detect and prevent. 
Employees already have access and knowledge about the structure and content of 
corporate databases. Insider attacks can be motivated by revenge or simply a feeling 
of entitlement. An example of the former is the case of Kenneth Patterson, fired 
from his position as data communications manager for American Eagle Outfitters. 
Patterson disabled the company’s ability to process credit card purchases during 
five days of the holiday season of 2002. As for a sense of entitlement, there have 
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always been many employees who felt entitled to take extra office supplies for 
home use, but this now extends to corporate data. An example is that of a vice 
president of sales for a stock analysis firm who quit to go to a competitor. Before she 
left, she copied the customer database to take with her. The offender reported 
feeling no animus toward her former employee; she simply wanted the data because 
it would be useful to her. 

Although IDS and IPS facilities can be useful in countering insider attacks, 
other more direct approaches are of higher priority. Examples include the following: 


e Enforce least privilege, only allowing access to the resources employees need 
to do their job. 


e Set logs to see what users access and what commands they are entering. 
e Protect sensitive resources with strong authentication. 
e Upon termination, delete employee’s computer and network access. 


e Upon termination, make a mirror image of employee’s hard drive before reis- 
suing it. That evidence might be needed if your company information turns up 
at a competitor. 


In this section, we look at the techniques used for intrusion. Then we examine 
ways to detect intrusion. 


Intrusion Techniques 


The objective of the intruder is to gain access to a system or to increase the range of 
privileges accessible on a system. Most initial attacks use system or software vulner- 
abilities that allow a user to execute code that opens a back door into the system. 
Alternatively, the intruder attempts to acquire information that should have been 
protected. In some cases, this information is in the form of a user password. With 
knowledge of some other user’s password, an intruder can log in to a system and 
exercise all the privileges accorded to the legitimate user. 

Typically, a system must maintain a file that associates a password with each 
authorized user. If such a file is stored with no protection, then it is an easy matter to 
gain access to it and learn passwords. The password file can be protected in one of 
two ways: 


e One-way function: The system stores only the value of a function based on the 
user’s password. When the user presents a password, the system transforms 
that password and compares it with the stored value. In practice, the system 
usually performs a one-way transformation (not reversible) in which the 
password is used to generate a key for the one-way function and in which a 
fixed-length output is produced. 


e Access control: Access to the password file is limited to one or a very few 
accounts. 


If one or both of these countermeasures are in place, some effort is needed for 
a potential intruder to learn passwords. On the basis of a survey of the literature and 
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interviews with a number of password crackers, [ALVA90] reports the following 
techniques for learning passwords: 


1. Try default passwords used with standard accounts that are shipped with the 
system. Many administrators do not bother to change these defaults. 


Nn 


Exhaustively try all short passwords (those of one to three characters). 


Ge 
. 


Try words in the system’s online dictionary or a list of likely passwords. Examples 
of the latter are readily available on hacker bulletin boards. 

4. Collect information about users, such as their full names, the names of their 
spouse and children, pictures in their office, and books in their office that are 
related to hobbies. 


mn 
. 


Try users’ phone numbers, Social Security numbers, and room numbers. 
6. Try all legitimate license plate numbers for this state. 
7. Use a Trojan horse (described in Chapter 21) to bypass restrictions on access. 


8. Tap the line between a remote user and the host system. 


The first six methods are various ways of guessing a password. If an intruder has 
to verify the guess by attempting to log in, it is a tedious and easily countered means of 
attack. For example, a system can simply reject any login after three password attempts, 
thus requiring the intruder to reconnect to the host to try again. Under these circum- 
stances, it is not practical to try more than a handful of passwords. However, the 
intruder is unlikely to try such crude methods. For example, if an intruder can gain 
access with a low level of privileges to an encrypted password file, then the strategy 
would be to capture that file and then use the encryption mechanism of that particular 
system at leisure until a valid password that provided greater privileges was discovered. 

Guessing attacks are feasible, and indeed highly effective, when a large num- 
ber of guesses can be attempted automatically and each guess verified, without the 
guessing process being detectable. Later in this chapter, we have much to say about 
thwarting guessing attacks. 

The seventh method of attack listed earlier, the Trojan horse, can be particularly 
difficult to counter. An example of a program that bypasses access controls was cited 
in [ALVA90]. A low-privilege user produced a game program and invited the system 
operator to use it in his or her spare time. The program did indeed play a game, but in 
the background it also contained code to copy the password file, which was unen- 
crypted but access protected, into the user’s file. Because the game was running under 
the operator’s high-privilege mode, it was able to gain access to the password file. 

The eighth attack listed, line tapping, is a matter of physical security. 

Other intrusion techniques do not require learning a password. Intruders can 
get access to a system by exploiting attacks such as buffer overflows on a program 
that runs with certain privileges. Privilege escalation can be done this way as well. 

We turn now to a discussion of the two principal countermeasures: detection 
and prevention. Detection is concerned with learning of an attack, either before or 
after its success. Prevention is a challenging security goal and an uphill battle at all 
times. The difficulty stems from the fact that the defender must attempt to thwart all 
possible attacks, whereas the attacker is free to try to find the weakest link in the 
defense chain and attack at that point. 
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20.2 INTRUSION DETECTION 


Inevitably, the best intrusion prevention system will fail. A system’s second line of 
defense is intrusion detection, and this has been the focus of much research in 
recent years. This interest is motivated by a number of considerations, including the 
following: 


1. If an intrusion is detected quickly enough, the intruder can be identified and 
ejected from the system before any damage is done or any data are compro- 
mised. Even if the detection is not sufficiently timely to preempt the intruder, 
the sooner that the intrusion is detected, the less the amount of damage and 
the more quickly that recovery can be achieved. 


nN 


. An effective intrusion detection system can serve as a deterrent, so acting to pre- 
vent intrusions. 


3. Intrusion detection enables the collection of information about intrusion tech- 
niques that can be used to strengthen the intrusion prevention facility. 


Intrusion detection is based on the assumption that the behavior of the 
intruder differs from that of a legitimate user in ways that can be quantified. Of 
course, we cannot expect that there will be a crisp, exact distinction between an 
attack by an intruder and the normal use of resources by an authorized user. Rather, 
we must expect that there will be some overlap. 

Figure 20.1 suggests, in very abstract terms, the nature of the task confronting 
the designer of an intrusion detection system. Although the typical behavior of an 
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Figure 20.1 Profiles of Behavior of Intruders and Authorized Users 
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intruder differs from the typical behavior of an authorized user, there is an overlap 
in these behaviors. Thus, a loose interpretation of intruder behavior, which will catch 
more intruders, will also lead to a number of “false positives,” or authorized users 
identified as intruders. On the other hand, an attempt to limit false positives by a 
tight interpretation of intruder behavior will lead to an increase in false negatives, or 
intruders not identified as intruders. Thus, there is an element of compromise and 
art in the practice of intrusion detection. 

In Anderson’s study [ANDE80], it was postulated that one could, with reason- 
able confidence, distinguish between a masquerader and a legitimate user. Patterns 
of legitimate user behavior can be established by observing past history, and signifi- 
cant deviation from such patterns can be detected. Anderson suggests that the task 
of detecting a misfeasor (legitimate user performing in an unauthorized fashion) is 
more difficult, in that the distinction between abnormal and normal behavior may 
be small. Anderson concluded that such violations would be undetectable solely 
through the search for anomalous behavior. However, misfeasor behavior might 
nevertheless be detectable by intelligent definition of the class of conditions that 
suggest unauthorized use. Finally, the detection of the clandestine user was felt to be 
beyond the scope of purely automated techniques. These observations, which were 
made in 1980, remain true today. 

[PORR92] identifies the following approaches to intrusion detection: 


1. Statistical anomaly detection: Involves the collection of data relating to the 
behavior of legitimate users over a period of time. Then statistical tests 
are applied to observed behavior to determine with a high level of confidence 
whether that behavior is not legitimate user behavior. 


a. Threshold detection: This approach involves defining thresholds, inde- 
pendent of user, for the frequency of occurrence of various events. 


b. Profile based: A profile of the activity of each user is developed and used 
to detect changes in the behavior of individual accounts. 


nN 


. Rule-based detection: Involves an attempt to define a set of rules that can be 
used to decide that a given behavior is that of an intruder. 


a. Anomaly detection: Rules are developed to detect deviation from previ- 
ous usage patterns. 


b. Penetration identification: An expert system approach that searches for 
suspicious behavior. 


In a nutshell, statistical approaches attempt to define normal, or expected, behavior, 
whereas rule-based approaches attempt to define proper behavior. 

In terms of the types of attackers listed earlier, statistical anomaly detection is 
effective against masqueraders, who are unlikely to mimic the behavior patterns of 
the accounts they appropriate. On the other hand, such techniques may be unable to 
deal with misfeasors. For such attacks, rule-based approaches may be able to recog- 
nize events and sequences that, in context, reveal penetration. In practice, a system 
may exhibit a combination of both approaches to be effective against a broad range 
of attacks. 
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Audit Records 


A fundamental tool for intrusion detection is the audit record. Some record of 
ongoing activity by users must be maintained as input to an intrusion detection 
system. Basically, two plans are used: 


Native audit records: Virtually all multiuser operating systems include 
accounting software that collects information on user activity. The advantage 
of using this information is that no additional collection software is needed. 
The disadvantage is that the native audit records may not contain the needed 
information or may not contain it in a convenient form. 


Detection-specific audit records: A collection facility can be implemented that 
generates audit records containing only that information required by the 
intrusion detection system. One advantage of such an approach is that it could 
be made vendor independent and ported to a variety of systems. The disad- 
vantage is the extra overhead involved in having, in effect, two accounting 
packages running on a machine. 


A good example of detection-specific audit records is one developed by 


Dorothy Denning [DENN87]. Each audit record contains the following fields: 


Subject: Initiators of actions. A subject is typically a terminal user but might 
also be a process acting on behalf of users or groups of users. All activity arises 
through commands issued by subjects. Subjects may be grouped into different 
access classes, and these classes may overlap. 


Action: Operation performed by the subject on or with an object; for example, 
login, read, perform I/O, execute. 


Object: Receptors of actions. Examples include files, programs, messages, 
records, terminals, printers, and user- or program-created structures. When a 
subject is the recipient of an action, such as electronic mail, then that subject is 
considered an object. Objects may be grouped by type. Object granularity may 
vary by object type and by environment. For example, database actions may be 
audited for the database as a whole or at the record level. 


Exception-Condition: Denotes which, if any, exception condition is raised on 
return. 


Resource-Usage: A list of quantitative elements in which each element gives 
the amount used of some resource (e.g., number of lines printed or displayed, 
number of records read or written, processor time, I/O units used, session 
elapsed time). 


Time-Stamp: Unique time-and-date stamp identifying when the action took 
place. 


Most user operations are made up of a number of elementary actions. For 


example, a file copy involves the execution of the user command, which includes 
doing access validation and setting up the copy, plus the read from one file, plus the 
write to another file. Consider the command 


: 
tz 
a 
tz 


COPY GAME.EXE TO <Libray>GAM 
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issued by Smith to copy an executable file GAME from the current directory to the 
<Library> directory. The following audit records may be generated: 


Smith | execute | <Library>COPY.EXE 0 CPU = 00002 11058721678 


Smith | read <Smith>GAME . EXE 0 RECORDS = 0 | 11058721679 


Smith | execute | <Library>COPY.EXE | write-viol | RECORDS = 0 | 11058721680 


In this case, the copy is aborted because Smith does not have write permission to 
<Library>. 

The decomposition of a user operation into elementary actions has three 
advantages: 


1. Because objects are the protectable entities in a system, the use of elementary 
actions enables an audit of all behavior affecting an object. Thus, the system 
can detect attempted subversions of access controls (by noting an abnormal- 
ity in the number of exception conditions returned) and can detect successful 
subversions by noting an abnormality in the set of objects accessible to the 
subject. 


nN 


. Single-object, single-action audit records simplify the model and the implemen- 
tation. 


3. Because of the simple, uniform structure of the detection-specific audit 
records, it may be relatively easy to obtain this information or at least part of 
it by a straightforward mapping from existing native audit records to the 
detection-specific audit records. 


Statistical Anomaly Detection 


As was mentioned, statistical anomaly detection techniques fall into two broad 
categories: threshold detection and profile-based systems. Threshold detection 
involves counting the number of occurrences of a specific event type over an inter- 
val of time. If the count surpasses what is considered a reasonable number that one 
might expect to occur, then intrusion is assumed. 

Threshold analysis, by itself, is a crude and ineffective detector of even moder- 
ately sophisticated attacks. Both the threshold and the time interval must be deter- 
mined. Because of the variability across users, such thresholds are likely to generate 
either a lot of false positives or a lot of false negatives. However, simple threshold 
detectors may be useful in conjunction with more sophisticated techniques. 

Profile-based anomaly detection focuses on characterizing the past behavior 
of individual users or related groups of users and then detecting significant devia- 
tions. A profile may consist of a set of parameters, so that deviation on just a single 
parameter may not be sufficient in itself to signal an alert. 

The foundation of this approach is an analysis of audit records. The audit 
records provide input to the intrusion detection function in two ways. First, the 
designer must decide on a number of quantitative metrics that can be used to mea- 
sure user behavior. An analysis of audit records over a period of time can be used to 
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determine the activity profile of the average user. Thus, the audit records serve to 
define typical behavior. Second, current audit records are the input used to detect 
intrusion. That is, the intrusion detection model analyzes incoming audit records to 
determine deviation from average behavior. 

Examples of metrics that are useful for profile-based intrusion detection are 
the following: 


e Counter: A nonnegative integer that may be incremented but not decre- 
mented until it is reset by management action. Typically, a count of certain 
event types is kept over a particular period of time. Examples include the 
number of logins by a single user during an hour, the number of times a given 
command is executed during a single user session, and the number of pass- 
word failures during a minute. 


e Gauge: A nonnegative integer that may be incremented or decremented. 
Typically, a gauge is used to measure the current value of some entity. 
Examples include the number of logical connections assigned to a user appli- 
cation and the number of outgoing messages queued for a user process. 


e Interval timer: The length of time between two related events. An example is 
the length of time between successive logins to an account. 


e Resource utilization: Quantity of resources consumed during a specified 
period. Examples include the number of pages printed during a user session 
and total time consumed by a program execution. 


Given these general metrics, various tests can be performed to determine 
whether current activity fits within acceptable limits. [DENN87] lists the following 
approaches that may be taken: 


e Mean and standard deviation 
e Multivariate 

e Markov process 

e Time series 


e Operational 


The simplest statistical test is to measure the mean and standard deviation of a 
parameter over some historical period. This gives a reflection of the average behav- 
ior and its variability. The use of mean and standard deviation is applicable to a wide 
variety of counters, timers, and resource measures. But these measures, by them- 
selves, are typically too crude for intrusion detection purposes. 

A multivariate model is based on correlations between two or more variables. 
Intruder behavior may be characterized with greater confidence by considering 
such correlations (for example, processor time and resource usage, or login fre- 
quency and session elapsed time). 

A Markov process model is used to establish transition probabilities among 
various states. As an example, this model might be used to look at transitions 
between certain commands. 


20.2 / INTRUSION DETECTION 20-13 


A time series model focuses on time intervals, looking for sequences of events 
that happen too rapidly or too slowly. A variety of statistical tests can be applied to 
characterize abnormal timing. 

Finally, an operational model is based on a judgment of what is considered 
abnormal, rather than an automated analysis of past audit records. Typically, fixed 
limits are defined and intrusion is suspected for an observation that is outside the 
limits. This type of approach works best where intruder behavior can be deduced 
from certain types of activities. For example, a large number of login attempts over 
a short period suggests an attempted intrusion. 

As an example of the use of these various metrics and models, Table 20.2 
shows various measures considered or tested for the Stanford Research Institute 
(SRI) intrusion detection system (IDES) [.DENN§87, JAV191, LUNT88]. 

The main advantage of the use of statistical profiles is that a prior knowledge of 
security flaws is not required. The detector program learns what is “normal” behavior 
and then looks for deviations. The approach is not based on system-dependent 
characteristics and vulnerabilities. Thus, it should be readily portable among a variety 
of systems. 


Rule-Based Intrusion Detection 


Rule-based techniques detect intrusion by observing events in the system and 
applying a set of rules that lead to a decision regarding whether a given pattern of 
activity is or is not suspicious. In very general terms, we can characterize all 
approaches as focusing on either anomaly detection or penetration identification, 
although there is some overlap in these approaches. 

Rule-based anomaly detection is similar in terms of its approach and strengths 
to statistical anomaly detection. With the rule-based approach, historical audit 
records are analyzed to identify usage patterns and to generate automatically rules 
that describe those patterns. Rules may represent past behavior patterns of users, 
programs, privileges, time slots, terminals, and so on. Current behavior is then 
observed, and each transaction is matched against the set of rules to determine if it 
conforms to any historically observed pattern of behavior. 

As with statistical anomaly detection, rule-based anomaly detection does not 
require knowledge of security vulnerabilities within the system. Rather, the scheme 
is based on observing past behavior and, in effect, assuming that the future will be 
like the past. In order for this approach to be effective, a rather large database of 
rules will be needed. For example, a scheme described in [VACC89] contains any- 
where from 104 to 10° rules. 

Rule-based penetration identification takes a very different approach to intru- 
sion detection. The key feature of such systems is the use of rules for identifying 
known penetrations or penetrations that would exploit known weaknesses. Rules 
can also be defined that identify suspicious behavior, even when the behavior is 
within the bounds of established patterns of usage. Typically, the rules used in these 
systems are specific to the machine and operating system. The most fruitful 
approach to developing such rules is to analyze attack tools and scripts collected on 
the Internet. These rules can be supplemented with rules generated by knowledge- 
able security personnel. In this latter case, the normal procedure is to interview 
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Table 20.2 Measures That May Be Used for Intrusion Detection 


Measure Model Type of Intrusion Detected 


Login and Session Activity 


Login frequency by day and Mean and standard _ Intruders may be likely to log in during off-hours. 
time deviation 


Frequency of login at different © Meanandstandard Intruders may log in from a location that a particu- 
locations deviation lar user rarely or never uses. 


Time since last login Operational Break-in on a “dead” account. 


Elapsed time per session Mean and standard _ Significant deviations might indicate masquerader. 
deviation 


Quantity of output to location Mean and standard _—_ Excessive amounts of data transmitted to remote 
deviation locations could signify leakage of sensitive data. 


Session resource utilization Mean and standard _—_ Unusual processor or I/O levels could signal an 
deviation intruder. 


Password failures at login Operational Attempted break-in by password guessing. 


Failures to login from specified | Operational Attempted break-in. 
terminals 


Command or Program Execution Activity 


Execution frequency Mean and standard May detect intruders, who are likely to use different 
deviation commands, or a successful penetration by a legiti- 
mate user, who has gained access to privileged 
commands. 


Program resource utilization Mean and standard An abnormal value might suggest injection of a 
deviation virus or Trojan horse, which performs side-effects 
that increase I/O or processor utilization. 


Execution denials Operational model _—- May detect penetration attempt by individual user 
who seeks higher privileges. 


File Access Activity 


Read, write, create, delete Mean and standard Abnormalities for read and write access for individ- 
frequency deviation ual users may signify masquerading or browsing. 


Records read, written Mean and standard Abnormality could signify an attempt to obtain sen- 
deviation sitive data by inference and aggregation. 


Failure count for read, write, Operational May detect users who persistently attempt to access 
create, delete unauthorized files. 


system administrators and security analysts to collect a suite of known penetration 
scenarios and key events that threaten the security of the target system. 

A simple example of the type of rules that can be used is found in NIDX, an 
early system that used heuristic rules that can be used to assign degrees of suspicion 
to activities [BAUE88]. Example heuristics are the following: 


1. Users should not read files in other users’ personal directories. 
2. Users must not write other users’ files. 
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3. Users who log in after hours often access the same files they used earlier. 


4. Users do not generally open disk devices directly but rely on higher-level operat- 
ing system utilities. 
5. Users should not be logged in more than once to the same system. 


6. Users do not make copies of system programs. 


The penetration identification scheme used in IDES is representative of the 
strategy followed. Audit records are examined as they are generated, and they are 
matched against the rule base. If a match is found, then the user’s suspicion rating is 
increased. If enough rules are matched, then the rating will pass a threshold that 
results in the reporting of an anomaly. 

The IDES approach is based on an examination of audit records. A weak- 
ness of this plan is its lack of flexibility. For a given penetration scenario, there 
may be a number of alternative audit record sequences that could be produced, 
each varying from the others slightly or in subtle ways. It may be difficult to pin 
down all these variations in explicit rules. Another method is to develop a higher- 
level model independent of specific audit records. An example of this is a state 
transition model known as USTAT [ILGU93]. USTAT deals in general actions 
rather than the detailed specific actions recorded by the UNIX auditing mecha- 
nism. USTAT is implemented on a SunOS system that provides audit records on 
239 events. Of these, only 28 are used by a preprocessor, which maps these onto 
10 general actions (Table 20.3). Using just these actions and the parameters that 
are invoked with each action, a state transition diagram is developed that charac- 
terizes suspicious activity. Because a number of different auditable events 
map into a smaller number of actions, the rule-creation process is simpler. 
Furthermore, the state transition diagram model is easily modified to accommo- 
date newly learned intrusion behaviors. 


Table 20.3. USTAT Actions versus SunOS Event Types 
USTAT Action 


SunOS Event Type 


Read open_r, open_rc, open_rtc, open_rwc, open_rwtc, open_rt, open_rw, 
open_rwt 


Write truncate, ftruncate, creat, open_rtc, open_rwe, open_rwtc, open_tt, 
open_rw, open_rwt, open_w, open_wt, open_wc, open_wct 


Create mkdir, creat, open_rc, open_rtc, open_rwe, open_rwtc, open_we, 
open_wtc, mknod 


Delete 
Execute 

Exit 
Modify_Owner 
Modify_Perm 
Rename 


Hardlink 


rmdir, unlink 
exec, execve 
exit 

chown, fchown 
chmod, fchmod 
rename 


link 
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The Base-Rate Fallacy 


To be of practical use, an intrusion detection system should detect a substantial 
percentage of intrusions while keeping the false alarm rate at an acceptable level. 
If only a modest percentage of actual intrusions are detected, the system provides 
a false sense of security. On the other hand, if the system frequently triggers an 
alert when there is no intrusion (a false alarm), then either system managers will 
begin to ignore the alarms, or much time will be wasted analyzing the false 
alarms. 

Unfortunately, because of the nature of the probabilities involved, it is very 
difficult to meet the standard of high rate of detections with a low rate of false 
alarms. In general, if the actual numbers of intrusions is low compared to the 
number of legitimate uses of a system, then the false alarm rate will be high unless 
the test is extremely discriminating. A study of existing intrusion detection systems, 
reported in [AXELO00], indicated that current systems have not overcome the prob- 
lem of the base-rate fallacy. See Appendix 20A for a brief background on the math- 
ematics of this problem. 


Distributed Intrusion Detection 


Until recently, work on intrusion detection systems focused on single-system stand- 
alone facilities. The typical organization, however, needs to defend a distributed 
collection of hosts supported by a LAN or internetwork. Although it is possible to 
mount a defense by using stand-alone intrusion detection systems on each host, a 
more effective defense can be achieved by coordination and cooperation among 
intrusion detection systems across the network. 

Porras points out the following major issues in the design of a distributed 
intrusion detection system [PORR92]: 


e A distributed intrusion detection system may need to deal with different audit 
record formats. In a heterogeneous environment, different systems will 
employ different native audit collection systems and, if using intrusion detec- 
tion, may employ different formats for security-related audit records. 


e One or more nodes in the network will serve as collection and analysis points 
for the data from the systems on the network. Thus, either raw audit data or 
summary data must be transmitted across the network. Therefore, there is a 
requirement to assure the integrity and confidentiality of these data. Integrity 
is required to prevent an intruder from masking his or her activities by altering 
the transmitted audit information. Confidentiality is required because the 
transmitted audit information could be valuable. 


e Either a centralized or decentralized architecture can be used. With a central- 
ized architecture, there is a single central point of collection and analysis of all 
audit data. This eases the task of correlating incoming reports but creates a 
potential bottleneck and single point of failure. With a decentralized architec- 
ture, there are more than one analysis centers, but these must coordinate their 
activities and exchange information. 


20.2 / INTRUSION DETECTION 20-17 


LAN monitor Host Host 


Cl Agent 


module 


Router 


Central manager 


Manager 
module 


Figure 20.2 Architecture for Distributed Intrusion Detection 


A good example of a distributed intrusion detection system is one developed 
at the University of California at Davis [HEBE92, SNAP91]. Figure 20.2 shows the 
overall architecture, which consists of three main components: 


e Host agent module: An audit collection module operating as a background 
process on a monitored system. Its purpose is to collect data on security- 
related events on the host and transmit these to the central manager. 


e LAN monitor agent module: Operates in the same fashion as a host 
agent module except that it analyzes LAN traffic and reports the results to the 
central manager. 


e Central manager module: Receives reports from LAN monitor and host 
agents and processes and correlates these reports to detect intrusion. 


The scheme is designed to be independent of any operating system or system 
auditing implementation. Figure 20.3 [SNAP91] shows the general approach that is 
taken. The agent captures each audit record produced by the native audit collection 
system. A filter is applied that retains only those records that are of security interest. 
These records are then reformatted into a standardized format referred to as the 
host audit record (HAR). Next, a template-driven logic module analyzes the 
records for suspicious activity. At the lowest level, the agent scans for notable events 
that are of interest independent of any past events. Examples include failed file 
accesses, accessing system files, and changing a file’s access control. At the next 
higher level, the agent looks for sequences of events, such as known attack patterns 
(signatures). Finally, the agent looks for anomalous behavior of an individual user 
based on a historical profile of that user, such as number of programs executed, 
number of files accessed, and the like. 
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Figure 20.3 Agent Architecture 


When suspicious activity is detected, an alert is sent to the central manager. 
The central manager includes an expert system that can draw inferences from 
received data. The manager may also query individual systems for copies of HARs 
to correlate with those from other agents. 

The LAN monitor agent also supplies information to the central manager. The 
LAN monitor agent audits host-host connections, services used, and volume of traf- 
fic. It searches for significant events, such as sudden changes in network load, the use 
of security-related services, and network activities such as rlogin. 

The architecture depicted in Figures 20.2 and 20.3 is quite general and flexible. 
It offers a foundation for a machine-independent approach that can expand from 
stand-alone intrusion detection to a system that is able to correlate activity from a 
number of sites and networks to detect suspicious activity that would otherwise 
remain undetected. 


Honeypots 


A relatively recent innovation in intrusion detection technology is the honeypot. 
Honeypots are decoy systems that are designed to lure a potential attacker away 
from critical systems. Honeypots are designed to 

e divert an attacker from accessing critical systems 

° collect information about the attacker’s activity 


e encourage the attacker to stay on the system long enough for administrators 
to respond 
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These systems are filled with fabricated information designed to appear valu- 
able but that a legitimate user of the system wouldn’t access. Thus, any access to the 
honeypot is suspect. The system is instrumented with sensitive monitors and event 
loggers that detect these accesses and collect information about the attacker’s activ- 
ities. Because any attack against the honeypot is made to seem successful, adminis- 
trators have time to mobilize and log and track the attacker without ever exposing 
productive systems. 

Initial efforts involved a single honeypot computer with IP addresses designed 
to attract hackers. More recent research has focused on building entire honeypot 
networks that emulate an enterprise, possibly with actual or simulated traffic and 
data. Once hackers are within the network, administrators can observe their behav- 
ior in detail and figure out defenses. 


Intrusion Detection Exchange Format 


To facilitate the development of distributed intrusion detection systems that can 
function across a wide range of platforms and environments, standards are needed 
to support interoperability. Such standards are the focus of the IETF Intrusion 
Detection Working Group. The purpose of the working group is to define data for- 
mats and exchange procedures for sharing information of interest to intrusion 
detection and response systems and to management systems that may need to inter- 
act with them. The outputs of this working group include: 


1. A requirements document, which describes the high-level functional require- 
ments for communication between intrusion detection systems and requirements 
for communication between intrusion detection systems and with management 
systems, including the rationale for those requirements. Scenarios will be used to 
illustrate the requirements. 


n 


A common intrusion language specification, which describes data formats that 
satisfy the requirements. 

3. A framework document, which identifies existing protocols best used for com- 
munication between intrusion detection systems, and describes how the 
devised data formats relate to them. 


As of this writing, all of these documents are in an Internet-draft document stage. 
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Password Protection 


The front line of defense against intruders is the password system. Virtually all 
multiuser systems require that a user provide not only a name or identifier (ID) but 
also a password. The password serves to authenticate the ID of the individual log- 
ging on to the system. In turn, the ID provides security in the following ways: 


e The ID determines whether the user is authorized to gain access to a system. 
In some systems, only those who already have an ID filed on the system are 
allowed to gain access. 
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e The ID determines the privileges accorded to the user. A few users may have 
supervisory or “superuser” status that enables them to read files and perform 
functions that are especially protected by the operating system. Some systems 
have guest or anonymous accounts, and users of these accounts have more 
limited privileges than others. 


e The ID is used in what is referred to as discretionary access control. For exam- 
ple, by listing the IDs of the other users, a user may grant permission to them 
to read files owned by that user. 


THE VULNERABILITY OF PAssworps To understand the nature of the threat to 
password-based systems, let us consider a scheme that is widely used on UNIX, in 
which passwords are never stored in the clear. Rather, the following procedure is 
employed (Figure 20.4a). Each user selects a password of up to eight printable 
characters in length. This is converted into a 56-bit value (using 7-bit ASCII) that 
serves as the key input to an encryption routine. The encryption routine, known as 
crypt(3), is based on DES. The DES algorithm is modified using a 12-bit “salt” value. 
Typically, this value is related to the time at which the password is assigned to the 
user. The modified DES algorithm is exercised with a data input consisting of a 
64-bit block of zeros. The output of the algorithm then serves as input for a second 
encryption. This process is repeated for a total of 25 encryptions. The resulting 64-bit 
output is then translated into an 11-character sequence. The hashed password is 
then stored, together with a plaintext copy of the salt, in the password file for the 
corresponding user ID. This method has been shown to be secure against a variety 
of cryptanalytic attacks [WAGNOO]. 

The salt serves three purposes: 


e It prevents duplicate passwords from being visible in the password file. Even if 
two users choose the same password, those passwords will be assigned at dif- 
ferent times. Hence, the “extended” passwords of the two users will differ. 


e It effectively increases the length of the password without requiring the user 
to remember two additional characters. Hence, the number of possible pass- 
words is increased by a factor of 4096, increasing the difficulty of guessing a 
password. 


e It prevents the use of a hardware implementation of DES, which would ease 
the difficulty of a brute-force guessing attack. 


When a user attempts to log on to a UNIX system, the user provides an ID and 
a password. The operating system uses the ID to index into the password file and 
retrieve the plaintext salt and the encrypted password. The salt and user-supplied 
password are used as input to the encryption routine. If the result matches the 
stored value, the password is accepted. 

The encryption routine is designed to discourage guessing attacks. Software 
implementations of DES are slow compared to hardware versions, and the use of 
25 iterations multiplies the time required by 25. However, since the original design 
of this algorithm, two changes have occurred. First, newer implementations of the 
algorithm itself have resulted in speedups. For example, the Morris worm described 
in Chapter 21 was able to do online password guessing of a few hundred passwords 
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Figure 20.4 UNIX Password Scheme 


in a reasonably short time by using a more efficient encryption algorithm than the 
standard one stored on the UNIX systems that it attacked. Second, hardware per- 
formance continues to increase, so that any software algorithm executes more 
quickly. 

Thus, there are two threats to the UNIX password scheme. First, a user can 
gain access on a machine using a guest account or by some other means and then 
run a password guessing program, called a password cracker, on that machine. The 
attacker should be able to check hundreds and perhaps thousands of possible pass- 
words with little resource consumption. In addition, if an opponent is able to obtain 
a copy of the password file, then a cracker program can be run on another machine 
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at leisure. This enables the opponent to run through many thousands of possible 
passwords in a reasonable period. 

As an example, a password cracker was reported on the Internet in August 
1993 [MADS93]. Using a Thinking Machines Corporation parallel computer, a 
performance of 1560 encryptions per second per vector unit was achieved. With four 
vector units per processing node (a standard configuration), this works out to 
800,000 encryptions per second on a 128-node machine (which is a modest size) and 
6.4 million encryptions per second on a 1024-node machine. 

Even these stupendous guessing rates do not yet make it feasible for an 
attacker to use a dumb brute-force technique of trying all possible combinations of 
characters to discover a password. Instead, password crackers rely on the fact that 
some people choose easily guessable passwords. 

Some users, when permitted to choose their own password, pick one that is 
absurdly short. The results of one study at Purdue University are shown in Table 20.4. 
The study observed password change choices on 54 machines, representing approxi- 
mately 7000 user accounts. Almost 3% of the passwords were three characters or 
fewer in length. An attacker could begin the attack by exhaustively testing all possi- 
ble passwords of length 3 or fewer. A simple remedy is for the system to reject any 
password choice of fewer than, say, six characters or even to require that all pass- 
words be exactly eight characters in length. Most users would not complain about 
such a restriction. 

Password length is only part of the problem. Many people, when permitted to 
choose their own password, pick a password that is guessable, such as their own 
name, their street name, a common dictionary word, and so forth. This makes the job 
of password cracking straightforward. The cracker simply has to test the password 
file against lists of likely passwords. Because many people use guessable passwords, 
such a strategy should succeed on virtually all systems. 

One demonstration of the effectiveness of guessing is reported in [KLEI90]. 
From a variety of sources, the author collected UNIX password files, containing 
nearly 14,000 encrypted passwords. The result, which the author rightly characterizes 


Table 20.4 Observed Password Lengths [SPAF92a] 
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as frightening, is shown in Table 20.5. In all, nearly one-fourth of the passwords were 
guessed. The following strategy was used: 


|. Try the user’s name, initials, account name, and other relevant personal infor- 
mation. In all, 130 different permutations for each user were tried. 


2. Try words from various dictionaries. The author compiled a dictionary of over 
60,000 words, including the online dictionary on the system itself, and various 
other lists as shown. 


Table 20.5 Passwords Cracked from a Sample Set of 13,797 Accounts [KLEI90] 


Type of Password Search Size Number of Percentage of Passwords Cost/Benefit 
Matches Matched Ratio? 


User/account name 2.7% 2.830 
Character sequences 0.2% 0.025 
Numbers 0.1% 0.021 
Chinese 0.4% 0.143 
Place names 0.6% 0.131 
Common names 4.0% 0.245 
Female names 1.2% 0.038 
Male names 1.0% 0.049 
Uncommon names 0.9% 0.026 
Myths & legends 0.5% 0.053 
Shakespearean 0.1% 0.023 
Sports terms 0.2% 0.134 
Science fiction 0.4% 0.085 
Movies and actors 0.1% 0.121 
Cartoons 0.1% 0.098 
Famous people 0.4% 0.190 


Phrases and patterns 1.8% 0.271 


Surnames 0.1% 0273 
Biology 0.0% 0.017 
System dictionary 74% 0.052 
Machine names 1.0% 0.015 
Mnemonics 0.0% 0.143 
King James bible 0.6% 0.011 
Miscellaneous words 0.4% 0.017 
Yiddish words 0.0% 0.000 
Asteroids 0.1% 0.007 
TOTAL 24.2% 0.053 


“Computed as the number of matches divided by the search size. The more words that needed to be tested for 
a match, the lower the cost/benefit ratio. 
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3. Try various permutations on the words from step 2. This included making the 
first letter uppercase or a control character, making the entire word uppercase, 
reversing the word, changing the letter “‘o” to the digit “zero,” and so on. These 
permutations added another 1 million words to the list. 


4. Try various capitalization permutations on the words from step 2 that were not 
considered in step 3. This added almost 2 million additional words to the list. 


Thus, the test involved in the neighborhood of 3 million words. Using the fastest 
Thinking Machines implementation listed earlier, the time to encrypt all these 
words for all possible salt values is under an hour. Keep in mind that such a thor- 
ough search could produce a success rate of about 25%, whereas even a single hit 
may be enough to gain a wide range of privileges on a system. 


ACCESS CONTROL One way to thwart a password attack is to deny the opponent 
access to the password file. If the encrypted password portion of the file is accessible 
only by a privileged user, then the opponent cannot read it without already knowing 
the password of a privileged user. [SPAF92a] points out several flaws in this strategy: 


e Many systems, including most UNIX systems, are susceptible to unanticipated 
break-ins. Once an attacker has gained access by some means, he or she may 
wish to obtain a collection of passwords in order to use different accounts for 
different logon sessions to decrease the risk of detection. Or a user with 
an account may desire another user’s account to access privileged data or to 
sabotage the system. 


e An accident of protection might render the password file readable, thus com- 
promising all the accounts. 


e Some of the users have accounts on other machines in other protection domains, 
and they use the same password. Thus, if the passwords could be read by anyone 
on one machine, a machine in another location might be compromised. 


Thus, a more effective strategy would be to force users to select passwords that are 
difficult to guess. 


Password Selection Strategies 


The lesson from the two experiments just described (Tables 20.4 and 20.5) is that, 
left to their own devices, many users choose a password that is too short or too easy 
to guess. At the other extreme, if users are assigned passwords consisting of eight 
randomly selected printable characters, password cracking is effectively impossible. 
But it would be almost as impossible for most users to remember their passwords. 
Fortunately, even if we limit the password universe to strings of characters that are 
reasonably memorable, the size of the universe is still too large to permit practical 
cracking. Our goal, then, is to eliminate guessable passwords while allowing the user 
to select a password that is memorable. Four basic techniques are in use: 


e User education 


e Computer-generated passwords 
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e Reactive password checking 


e Proactive password checking 


Users can be told the importance of using hard-to-guess passwords and can be 
provided with guidelines for selecting strong passwords. This user education strat- 
egy is unlikely to succeed at most installations, particularly where there is a large 
user population or a lot of turnover. Many users will simply ignore the guidelines. 
Others may not be good judges of what is a strong password. For example, many 
users (mistakenly) believe that reversing a word or capitalizing the last letter makes 
a password unguessable. 

Computer-generated passwords also have problems. If the passwords are quite 
random in nature, users will not be able to remember them. Even if the password is 
pronounceable, the user may have difficulty remembering it and so be tempted to 
write it down. In general, computer-generated password schemes have a history of 
poor acceptance by users. FIPS PUB 181 defines one of the best-designed auto- 
mated password generators. The standard includes not only a description of the 
approach but also a complete listing of the C source code of the algorithm. The algo- 
rithm generates words by forming pronounceable syllables and concatenating them 
to form a word. A random number generator produces a random stream of charac- 
ters used to construct the syllables and words. 

A reactive password checking strategy is one in which the system periodically 
runs its own password cracker to find guessable passwords. The system cancels any 
passwords that are guessed and notifies the user. This tactic has a number of draw- 
backs. First, it is resource intensive if the job is done right. Because a determined 
opponent who is able to steal a password file can devote full CPU time to the task 
for hours or even days, an effective reactive password checker is at a distinct disad- 
vantage. Furthermore, any existing passwords remain vulnerable until the reactive 
password checker finds them. 

The most promising approach to improved password security is a proactive 
password checker. In this scheme, a user is allowed to select his or her own pass- 
word. However, at the time of selection, the system checks to see if the password is 
allowable and, if not, rejects it. Such checkers are based on the philosophy that, 
with sufficient guidance from the system, users can select memorable passwords 
from a fairly large password space that are not likely to be guessed in a dictionary 
attack. 

The trick with a proactive password checker is to strike a balance between 
user acceptability and strength. If the system rejects too many passwords, users will 
complain that it is too hard to select a password. If the system uses some simple 
algorithm to define what is acceptable, this provides guidance to password crackers 
to refine their guessing technique. In the remainder of this subsection, we look at 
possible approaches to proactive password checking. 

The first approach is a simple system for rule enforcement. For example, the 
following rules could be enforced: 


e All passwords must be at least eight characters long. 


e In the first eight characters, the passwords must include at least one each of 
uppercase, lowercase, numeric digits, and punctuation marks. 
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These rules could be coupled with advice to the user. Although this approach is 
superior to simply educating users, it may not be sufficient to thwart password 
crackers. This scheme alerts crackers as to which passwords not to try but may still 
make it possible to do password cracking. 

Another possible procedure is simply to compile a large dictionary of possible 
“bad” passwords. When a user selects a password, the system checks to make sure 
that it is not on the disapproved list. There are two problems with this approach: 


e Space: The dictionary must be very large to be effective. For example, the dic- 
tionary used in the Purdue study [SPAF92a] occupies more than 30 megabytes 
of storage. 


e Time: The time required to search a large dictionary may itself be large. In 
addition, to check for likely permutations of dictionary words, either those 
words most be included in the dictionary, making it truly huge, or each search 
must also involve considerable processing. 


Two techniques for developing an effective and efficient proactive password 
checker that is based on rejecting words on a list show promise. One of these develops 
a Markov model for the generation of guessable passwords [DAVI93]. Figure 20.5 
shows a simplified version of such a model. This model shows a language consisting of 
an alphabet of three characters. The state of the system at any time is the identity of 
the most recent letter. The value on the transition from one state to another repre- 
sents the probability that one letter follows another. Thus, the probability that the next 
letter is b, given that the current letter is a, is 0.5. 


M = {3, {a,b,c}, T, 1} where 
, 0.0 0.5 0.5 | 
T= 0.2 04 04 
10 00 0.0 


e.g., string probably from this language: abbcacaba 
e.g., string probably not from this language: aacccbaaa 


Figure 20.5 An Example Markov Model 
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In general, a Markov model is a quadruple [m, A, T, k], where m is the number 
of states in the model, A is the state space, T is the matrix of transition probabilities, 
and k is the order of the model. For a kth-order model, the probability of making a 
transition to a particular letter depends on the previous k letters that have been gen- 
erated. Figure 20.5 shows a simple first-order model. 

The authors report on the development and use of a second-order model. To 
begin, a dictionary of guessable passwords is constructed. Then the transition matrix 
is calculated as follows: 


1. Determine the frequency matrix f, where f(i, j, k) is the number of occurrences 
of the trigram consisting of the ith, jth, and Ath character. For example, the 
password parsnips yields the trigrams par, ars, rsn, sni, nip, and ips. 

2. For each bigram jj, calculate f(i, 7, oo) as the total number of trigrams beginning 
with ij. For example, f(a, b, 00) would be the total number of trigrams of the form 
aba, abb, abc, and so on. 


3. Compute the entries of T as follows: 
f(i, j,k) 
NeL@) = go. . 
(4,7,) is 


The result is a model that reflects the structure of the words in the dictionary. 
With this model, the question “Is this a bad password?” is transformed into the 
question “Was this string (password) generated by this Markov model?” For a given 
password, the transition probabilities of all its trigrams can be looked up. Some stan- 
dard statistical tests can then be used to determine if the password is likely or 
unlikely for that model. Passwords that are likely to be generated by the model are 
rejected. The authors report good results for a second-order model. Their system 
catches virtually all the passwords in their dictionary and does not exclude so many 
potentially good passwords as to be user unfriendly. 

A quite different approach has been reported by Spafford [SPAF92a, 
SPAF92b]. It is based on the use of a Bloom filter [BLOO70]. To begin, we explain 
the operation of the Bloom filter. A Bloom filter of order k consists of a set of k 
independent hash functions H,(x), H>(x),..., H,(x), where each function maps a 
password into a hash value in the range 0 to N — 1. That is, 


H{Xj) = y 1s<isk; 1<j<D; O<sysN-1 
where 

Xj = jth word in password dictionary 

D = number of words in password dictionary 

The following procedure is then applied to the dictionary: 


1. A hash table of N bits is defined, with all bits initially set to 0. 


2. For each password, its k hash values are calculated, and the corresponding bits 
in the hash table are set to 1. Thus, if H,(X;) = 67 for some (i, j), then the sixty- 
seventh bit of the hash table is set to 1; if the bit already has the value 1, it 
remains at 1. 
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When a new password is presented to the checker, its k hash values are calcu- 
lated. If all the corresponding bits of the hash table are equal to 1, then the password 
is rejected. All passwords in the dictionary will be rejected. But there will also be 
some “false positives” (that is, passwords that are not in the dictionary but that pro- 
duce a match in the hash table). To see this, consider a scheme with two hash func- 
tions. Suppose that the passwords undertaker and hulkhogan are in the dictionary, 
but xG%#jj98 is not. Further suppose that 


H,(undertaker) = 25 H,(hulkhogan) = 83 HH, (xG%#jj98) = 665 
H,(undertaker) = 998  H(hulkhogan) = 665 H>(xG%#jj98) = 998 

If the password xG%#jj98 is presented to the system, it will be rejected even 
though it is not in the dictionary. If there are too many such false positives, it will be 
difficult for users to select passwords. Therefore, we would like to design the hash 


scheme to minimize false positives. It can be shown that the probability of a false 
positive can be approximated by: 


k k 
Pwr (1 _ oto) = (1 _ ott) 


Tk 
In(1 — Pl‘) 


or, equivalently, 


nN 
~ 


where 


k = number of hash functions 

N = number of bits in hash table 

D = number of words in dictionary 

R = N/D, ratio of hash table size (bits) to dictionary size (words) 


Figure 20.6 plots P as a function of R for various values of k. Suppose we have 
a dictionary of 1 million words and we wish to have a 0.01 probability of rejecting a 
password not in the dictionary. If we choose six hash functions, the required ratio is 
R = 9.6. Therefore, we need a hash table of 9.6 X 10°bits or about 1.2 MBytes of 
storage. In contrast, storage of the entire dictionary would require on the order of 
8 MBytes. Thus, we achieve a compression of almost a factor of 7. Furthermore, 
password checking involves the straightforward calculation of six hash functions 
and is independent of the size of the dictionary, whereas with the use of the full 
dictionary, there is substantial searching.! 


'Both the Markov model and the Bloom filter involve the use of probabilistic techniques. In the case of 
the Markov model, there is a small probability that some passwords in the dictionary will not be caught 
and a small probability that some passwords not in the dictionary will be rejected. In the case of the 
Bloom filter, there is a small probability that some passwords not in the dictionary will be rejected. Again 
we see that taking a probabilistic approach simplifies the solution (e.g., see the Miller-Rabin algorithm in 
Chapter 8). 
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Figure 20.6 Performance of Bloom Filter 
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Two thorough treatments of intrusion detection are [BACE00] and [PROCO1]. A more 
concise but very worthwhile treatment is [SCARO7]. Two short but useful survey articles on 
the subject are [KENTO00] and [MCHU00]. [NING04] surveys recent advances in intrusion 
detection techniques. [HONE01] is the definitive account on honeypots and provides a 
detailed analysis of the tools and methods of hackers. 


BACE00 Bace, R. Intrusion Detection. Indianapolis, IN: Macmillan Technical 
Publishing, 2000. 

HONE01 The Honeynet Project. Know Your Enemy: Revealing the Security Tools, Tactics, 
and Motives of the Blackhat Community. Reading, MA: Addison-Wesley, 2001. 
KENTO00 Kent, S. “On the Trail of Intrusions into Information Systems.” [EEE 

Spectrum, December 2000. 


MCHU00 McHugh, J.; Christie, A.; and Allen, J. “The Role of Intrusion Detection 


Systems.” JEEE Software, September/October 2000. 

NING04 Ning, P., et al. “Techniques and Tools for Analyzing Intrusion Alerts.” ACM 
Transactions on Information and System Security, May 2004. 

PROCO1 Proctor, P., The Practical Intrusion Detection Handbook. Upper Saddle River, 
NJ: Prentice Hall, 2001. 

SCAR07_ Scarfone, K.,and Mell, P. Guide to Intrusion Detection and Prevention Systems. 
NIST Special Publication SP 800-94, February 2007. 
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WS 


Recommended Web Sites: 


e CERT Coordination Center: The organization that grew from the computer 
emergency response team formed by the Defense Advanced Research Projects 
Agency. Site provides good information on Internet security threats, vulnerabilities, 
and attack statistics. 

e Packet Storm: Resource of up-to-date and historical security tools, exploits, and 
advisories. 

e Honeynet Project: A research project studying the techniques of predatory hackers 
and developing honeypot products. 

e Honeypots: A good collection of research papers and technical articles. 

e Intrusion Detection Working Group: IETF group developing standards for exchange 
formats and exchange procedures for intrusion detection systems. Includes RFCs and 
Internet drafts. 

e STAT Project: A research and open-source project at the U. of California, Santa 
Barbara that focuses on signature-based intrusion detection tools for hosts, applica- 
tions, and networks. 


e Password Usage and Generation: NIST documents on this topic. 
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Key Terms 


audit record intruder password 
Bayes’ Theorem intrusion detection rule-based intrusion detection 


base-rate fallacy intrusion detection exchange salt 
honeypot format statistical anomaly detection 


Review Questions 


20.1 List and briefly define three classes of intruders. 
20.2 What are two common techniques used to protect a password file? 
20.3 What are three benefits that can be provided by an intrusion detection system? 


20.4 What is the difference between statistical anomaly detection and rule-based intrusion 
detection? 

20.5 What metrics are useful for profile-based intrusion detection? 

20.6 What is the difference between rule-based anomaly detection and rule-based pene- 
tration identification? 

20.7 What is a honeypot? 

20.8 What is a salt in the context of UNIX password management? 

20.9 List and briefly define four techniques used to avoid guessable passwords. 
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Problems 


20.1 


20.2 


20.4 


In the context of an IDS, we define a false positive to be an alarm generated by an 
IDS in which the IDS alerts to a condition that is actually benign. A false negative 
occurs when an IDS fails to generate an alarm when an alert-worthy condition is in 
effect. Using the following diagram, depict two curves that roughly indicate false 
positives and false negatives, respectively. 


Frequency 
of alerts 
Less specific Conservativeness Mote specific 
or looser of signatures or stricter 


The overlapping area of the two probability density functions of Figure 20.1 repre- 
sents the region in which there is the potential for false positives and false negatives. 
Further, Figure 20.1 is an idealized and not necessarily representative depiction of the 
relative shapes of the two density functions. Suppose there is 1 actual intrusion for 
every 1000 authorized users, and the overlapping area covers 1% of the authorized 
users and 50% of the intruders. 
a. Sketch such a set of density functions and argue that this is not an unreasonable 
depiction. 
b. What is the probability that an event that occurs in this region is that of an autho- 
rized user? Keep in mind that 50% of all intrusions fall in this region. 
An example of a host-based intrusion detection tool is the tripwire program. This is a 
file integrity checking tool that scans files and directories on the system on a regular 
basis and notifies the administrator of any changes. It uses a protected database of 
cryptographic checksums for each file checked and compares this value with that 
recomputed on each file as it is scanned. It must be configured with a list of files and 
directories to check, and what changes, if any, are permissible to each. It can allow, for 
example, log files to have new entries appended, but not for existing entries to be 
changed. What are the advantages and disadvantages of using such a tool? Consider 
the problem of determining which files should only change rarely, which files may 
change more often and how, and which change frequently and hence cannot be 
checked. Hence consider the amount of work in both the configuration of the pro- 
gram and on the system administrator monitoring the responses generated. 
A taxicab was involved in a fatal hit-and-run accident at night. Two cab companies, 
the Green and the Blue, operate in the city. You are told that: 


° 85% of the cabs in the city are Green and 15% are Blue. 
e Awitness identified the cab as Blue. 


The court tested the reliability of the witness under the same circumstances that 
existed on the night of the accident and concluded that the witness was correct in 
identifying the color of the cab 80% of the time. What is the probability that the cab 
involved in the incident was Blue rather than Green? 
Explain the suitability or unsuitability of the following passwords: 

a. YK 334 __b. mfmitm (for “my favorite c. Nataliel d. Washington 

movie is tender mercies) 
e. Aristotle f. tv9stove g. 12345678 h. dribgib 
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20.6 


20.7 


20.8 


20.9 


20.10 


20.11 


20.12 


20.13 


20.14 


20.15 


An early attempt to force users to use less predictable passwords involved computer- 
supplied passwords. The passwords were eight characters long and were taken from 
the character set consisting of lowercase letters and digits. They were generated by a 
pseudorandom number generator with 2!° possible starting values. Using the technol- 
ogy of the time, the time required to search through all character strings of length 8 
from a 36-character alphabet was 112 years. Unfortunately, this is not a true reflection 
of the actual security of the system. Explain the problem. 
Assume that passwords are selected from four-character combinations of 26 alpha- 
betic characters. Assume that an adversary is able to attempt passwords at a rate of 
one per second. 
a. Assuming no feedback to the adversary until each attempt has been completed, 
what is the expected time to discover the correct password? 
b. Assuming feedback to the adversary flagging an error as each incorrect character 
is entered, what is the expected time to discover the correct password? 
Assume that source elements of length k are mapped in some uniform fashion into a 
target elements of length p. If each digit can take on one of r values, then the number 
of source elements is r and the number of target elements is the smaller number 7”. 
A particular source element x; is mapped to a particular target element y;. 
a. What is the probability that the correct source element can be 
selected by an adversary on one try? 
b. What is the probability that a different source element x,(x; # x,) that results in 
the same target element, Yjp could be produced by an adversary? 
c. What is the probability that the correct target element can be produced by an 
adversary on one try? 
A phonetic password generator picks two segments randomly for each six-letter pass- 
word. The form of each segment is CVC (consonant, vowel, consonant), where 
V = <a,e,i,0,u> andC = V. 
a. What is the total password population? 
b. What is the probability of an adversary guessing a password correctly? 
Assume that passwords are limited to the use of the 95 printable ASCII characters 
and that all passwords are 10 characters in length. Assume a password cracker with an 
encryption rate of 6.4 million encryptions per second. How long will it take to test 
exhaustively all possible passwords on a UNIX system? 
Because of the known risks of the UNIX password system, the SunOS-4.0 documen- 
tation recommends that the password file be removed and replaced with a publicly 
readable file called /etc/publickey. An entry in the file for user A consists of a user’s 
identifier JD ,, the user’s public key, PU,, and the corresponding private key PR,. This 
private key is encrypted using DES with a key derived from the user’s login password 
P,. When A logs in, the system decrypts E(P,, PR,) to obtain PR,. 
a. The system then verifies that P, was correctly supplied. How? 
b. How can an opponent attack this system? 
The encryption scheme used for UNIX passwords is one way; it is not possible to 
reverse it. Therefore, would it be accurate to say that this is, in fact, a hash code rather 
than an encryption of the password? 
It was stated that the inclusion of the salt in the UNIX password scheme increases the 
difficulty of guessing by a factor of 4096. But the salt is stored in plaintext in the same 
entry as the corresponding ciphertext password. Therefore, those two characters are 
known to the attacker and need not be guessed. Why is it asserted that the salt 
increases security? 
Assuming that you have successfully answered the preceding problem and under- 
stand the significance of the salt, here is another question. Wouldn’t it be possible to 
thwart completely all password crackers by dramatically increasing the salt size to, 
say, 24 or 48 bits? 
Consider the Bloom filter discussed in Section 20.3. Define A = number of hash func- 
tions; VN = number of bits in hash table; and D = number of words in dictionary. 
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a. Show that the expected number of bits in the hash table that are equal to zero is 


expressed as 
k D 
=({-— 
ee 


b. Show that the probability that an input word, not in the dictionary, will be falsely 
accepted as being in the dictionary is 
P= (1-4) 


c. Show that the preceding expression can be approximated as 


Pe (1 = eton) 


20.16 Design a file access system to allow certain users read and write access to a file, 
depending on authorization set up by the system. The instructions should be of the 
format: 


READ (F, User A): attempt by User A to read file F 
READ (F, User A): attempt by User A to store a possibly modified copy of F 


Each file has a header record, which contains authorization privileges; that is, a list of 
users who can read and write. The file is to be encrypted by a key that is not shared by 
the users but known only to the system. 


APPENDIX 20A THE BASE-RATE FALLACY 


We begin with a review of important results from probability theory, then demon- 
strate the base-rate fallacy. 


Conditional Probability and Independence 


We often want to know a probability that is conditional on some event. The effect of the 
condition is to remove some of the outcomes from the sample space. For example, what 
is the probability of getting a sum of 8 on the roll of two dice, if we know that the face of 
at least one die is an even number? We can reason as follows. Because one die is even 
and the sum is even, the second die must show an even number. Thus, there are three 
equally likely successful outcomes: (2,6), (4,4) and (6, 2), out of a total set of possibilities 
of [36—(number of events with both faces odd)] = 36—(3 X 3) = 27. The resulting 
probability is 3/27 = 1/9. 

Formally, the conditional probability of an event A assuming the event B has 
occurred, denoted by Pr[A! B], is defined as the ratio 


Pr[AB] 
Pr[B] 


Pr[A | B] = 


where we assume Pr[B] is not zero. 

In our example, A = {sum of 8} and B = {at least one die even}. The quantity 
Pr[AB] encompasses all of those outcomes in which the sum is 8 and at least one 
die is even. As we have seen, there are three such outcomes. Thus, 
Pr[AB] = 3/36 = 1/12. A moment’s thought should convince you that Pr[B] = 3/4. 
We can now calculate 
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1/12 1 
Pr[A| B] = —— = — 
MAIBI = sq = 9 
This agrees with our previous reasoning. 
Two events A and B are called independent if Pr[AB] = Pr[A]Pr[B]. It can eas- 
ily be seen that if A and B are independent, Pr[AIB] = Pr[A] and Pr[BIA] = Pr[B]. 


Bayes’ Theorem 


One of the most important results from probability theory is known as Bayes’ theo- 
rem. First we need to state the total probability formula. Given a set of mutually 
exclusive events FE), E>, ..., E,,such that the union of these events covers all possi- 
ble outcomes, and given an arbitrary event A, then it can be shown that 


Pr[A] = >) Pr[AlE]Pr[E,] (20.1) 
i=1 
Bayes’ theorem may be stated as follows: 
Pr[AlE;]P[E; Pr[AlE;]P[E; 
prea] = Ut PLAT 1 _ : LAE PLE (20.2) 
Pr[AIE|]Pr[E;] 
=1 


J 


Figure 20.7a illustrates the concepts of total probability and Bayes’ theorem. 

Bayes’ theorem is used to calculate “posterior odds,” that is, the probability 
that something really is the case, given evidence in favor of it. For example, suppose 
we are transmitting a sequence of zeroes and ones over a noisy transmission line. 
Let SO and S1 be the events a zero is sent at a given time and a one is sent, respec- 
tively, and RO and R1 be the events that a zero is received and a one is received. 
Suppose we know the probabilities of the source, namely Pr[S1] = p and 
Pr[SO] = 1 — p. Now the line is observed to determine how frequently an error 
occurs when a one is sent and when a zero is sent, and the following probabilities are 
calculated: Pr[ROISO] = p, and Pr[R1ISO] = pj. If a zero is received, we can then 


= SO; 0 sent = RO; 0 received 
=S1;1sent [j= RI; 1 received 
(a) Diagram to illustrate concepts (b) Example 


Figure 20.7 Illustration of Total Probability and Bayes’ Theorem 
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calculate the conditional probability of an error, namely the conditional probability 
that a one was sent given that a zero was received, using Bayes’ theorem: 


Pr[RO | S1]Pr[S1] _ PaP 
Pr[RO | S1]Pr[S1] + Pr[RO| SO]Pr[SO] pap + (1 — pp )(1 — p) 


Pr[S1 | RO] = 


Figure 20.7b illustrates the preceding equation. In the figure, the sample space is 
represented by a unit square. Half of the square corresponds to SO and half to S1, so 
Pr[SO] = Pr[S1] = 0.5. Similarly, half of the square corresponds to RO and half to R1,so 
Pr[RO] = Pr[R1] = 0.5. Within the area representing SO, 1/4 of that area corresponds to 
R1,so Pr[R1/SO] = 0.25. Other conditional probabilities are similarly evident. 


The Base-Rate Fallacy Demonstrated 


Consider the following situation. A patient has a test for some disease that comes 
back positive (indicating he has the disease). You are told that 


e The accuracy of the test is 87% (i.e., if a patient has the disease, 87% of the 
time, the test yields the correct result, and if the patient does not have the dis- 
ease, 87% of the time, the test yields the correct result). 


e The incidence of the disease in the population is 1%. 


Given that the test is positive, how probable is it that the patient does not have 
the disease? That is, what is the probability that this is a false alarm? We need Bayes’ 
theorem to get the correct answer: 


Pr[positive/well]Pr[well] 


Pr[well/positi = 
ceo Pr[positive/disease]Pr[disease] + Pr[positive/well]Pr[well] 


(0.13)(0.99) 
~ (0.87)(0.01) + (0.13)(0.99) 


= 0.937 


Thus, in the vast majority of cases, when a disease condition is detected, it is a 
false alarm. 

This problem, used in a study [PIAT91], was presented to a number of people. 
Most subjects gave the answer 13%. The vast majority, including many physicians, 
gave a number below 50%. Many physicians who guessed wrong lamented, “If you 
are right, there is no point in making clinical tests!” The reason most people get it 
wrong is that they do not take into account the basic rate of incidence (the base rate) 
when intuitively solving the problem. This error is known as the base-rate fallacy. 

How could this problem be fixed? Suppose we could drive both of the correct 
result rates to 99.9%. That is, suppose we have Pr[positive/disease] = 0.999 and 
Pr[negative/well] = 0.999. Plugging these numbers into the Equation (20.2), we get 
Pr[well/positive] = 0.09. Thus, if we can accurately detect disease and accurately 
detect lack of disease at a level of 99.9%, then the rate of false alarms will be 9%. 
This is much better, but still not ideal. Moreover, again assume 99.9% accuracy, but 
now suppose that the incidence of the disease in the population is only 
1/10000 = 0.0001. We then end up with a rate of false alarms of 91%. In actual situ- 
ations, [AXELO0] found that the probabilities associated with intrusion detection 
systems were such that the false alarm rate was unsatisfactory. 
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What is the concept of defense: The parrying of a blow. What is its characteristic 
feature: Awaiting the blow. 


—On War, Carl Von Clausewitz 


KEY POINTS 


® Malicious software is software that is intentionally included or inserted in 
a system for a harmful purpose. 


® A virus is a piece of software that can “infect” other programs by modify- 
ing them; the modification includes a copy of the virus program, which can 
then go on to infect other programs. 


® A worm is a program that can replicate itself and send copies from com- 
puter to computer across network connections. Upon arrival, the worm 
may be activated to replicate and propagate again. In addition to propaga- 
tion, the worm usually performs some unwanted function. 


® A denial of service (DoS) attack is an attempt to prevent legitimate users 
of a service from using that service. 


® A distributed denial of service attack is launched from multiple coordinated 
sources. 


Perhaps the most sophisticated types of threats to computer systems are presented by 
programs that exploit vulnerabilities in computing systems. Such threats are referred to 
as malicious software, or malware. In this context, we are concerned with threats to 
application programs as well as utility programs, such as editors and compilers, and 
kernel-level programs. 

This chapter examines malicious software, with a special emphasis on viruses 
and worms. The chapter begins with a survey of various types of malware, with a 
more detailed look at the nature of viruses and worms. We then turn to distributed 
denial-of-service attacks. Throughout, the discussion presents both threats and 
countermeasures. 


21.1 TYPES OF MALICIOUS SOFTWARE 


The terminology in this area presents problems because of a lack of universal agree- 
ment on all of the terms and because some of the categories overlap. Table 21.1 is a 
useful guide. 

Malicious software can be divided into two categories: those that need a host 
program, and those that are independent. The former, referred to as parasitic, are 
essentially fragments of programs that cannot exist independently of some 
actual application program, utility, or system program. Viruses, logic bombs, 
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Terminology of Malicious Programs 


Name Description 
Virus Malware that, when executed, tries to replicate itself into other executable code; when it 
succeeds the code is said to be infected. When the infected code is executed, the virus also 
executes. 
Worm A computer program that can run independently and can propagate a complete working 


version of itself onto other hosts on a network. 


Logic bomb A program inserted into software by an intruder. A logic bomb lies dormant until a prede- 
fined condition is met; the program then triggers an unauthorized act. 


Trojan horse A computer program that appears to have a useful function, but also has a hidden and 
potentially malicious function that evades security mechanisms, sometimes by exploiting 
legitimate authorizations of a system entity that invokes the Trojan horse program. 


Backdoor Any mechanism that bypasses a normal security check; it may allow unauthorized access 
(trapdoor) to functionality. 
Mobile code Software (e.g., script, macro, or other portable instruction) that can be shipped unchanged 


to a heterogeneous collection of platforms and execute with identical semantics. 


Exploits Code specific to a single vulnerability or set of vulnerabilities. 


Downloaders Program that installs other items on a machine that is under attack. Usually, a downloader 
is sent in an e-mail. 


Auto-rooter Malicious hacker tools used to break into new machines remotely. 

Kit (virus Set of tools for generating new viruses automatically. 

generator) 

Spammer Used to send large volumes of unwanted e-mail. 

programs 

Flooders Used to attack networked computer systems with a large volume of traffic to carry out a 


denial-of-service (DoS) attack. 


Keyloggers Captures keystrokes on a compromised system. 


Rootkit Set of hacker tools used after attacker has broken into a computer system and gained 
root-level access. 


Zombie, bot Program activated on an infected machine that is activated to launch attacks on other 
machines. 

Spyware Software that collects information from a computer and transmits it to another system. 

Adware Advertising that is integrated into software. It can result in pop-up ads or redirection of a 


browser to a commercial site. 


and backdoors are examples. Independent malware is a self-contained program 
that can be scheduled and run by the operating system. Worms and bot programs 
are examples. 

We can also differentiate between those software threats that do not repli- 
cate and those that do. The former are programs or fragments of programs that 
are activated by a trigger. Examples are logic bombs, backdoors, and bot pro- 
grams. The latter consist of either a program fragment or an independent 
program that, when executed, may produce one or more copies of itself to be 
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activated later on the same system or some other system. Viruses and worms are 
examples. 

In the remainder of this section, we briefly survey some of the key categories 
of malicious software, deferring discussion on the key topics of viruses and worms 
until the following sections. 


Backdoor 


A backdoor, also known as a trapdoor, is a secret entry point into a program that 
allows someone who is aware of the backdoor to gain access without going through 
the usual security access procedures. Programmers have used backdoors legiti- 
mately for many years to debug and test programs; such a backdoor is called a 
maintenance hook. This usually is done when the programmer is developing an 
application that has an authentication procedure, or a long setup, requiring the user 
to enter many different values to run the application. To debug the program, the 
developer may wish to gain special privileges or to avoid all the necessary setup and 
authentication. The programmer may also want to ensure that there is a method of 
activating the program should something be wrong with the authentication proce- 
dure that is being built into the application. The backdoor is code that recognizes 
some special sequence of input or is triggered by being run from a certain user ID or 
by an unlikely sequence of events. 

Backdoors become threats when unscrupulous programmers use them to 
gain unauthorized access. The backdoor was the basic idea for the vulnerability 
portrayed in the movie War Games. Another example is that during the develop- 
ment of Multics, penetration tests were conducted by an Air Force “tiger team” 
(simulating adversaries). One tactic employed was to send a bogus operating 
system update to a site running Multics. The update contained a Trojan horse 
(described later) that could be activated by a backdoor and that allowed the 
tiger team to gain access. The threat was so well implemented that the Multics 
developers could not find it, even after they were informed of its presence 
[ENGE80]. 

It is difficult to implement operating system controls for backdoors. 
Security measures must focus on the program development and software update 
activities. 


Logic Bomb 


One of the oldest types of program threat, predating viruses and worms, is the 
logic bomb. The logic bomb is code embedded in some legitimate program that is 
set to “explode” when certain conditions are met. Examples of conditions that 
can be used as triggers for a logic bomb are the presence or absence of certain 
files, a particular day of the week or date, or a particular user running the appli- 
cation. Once triggered, a bomb may alter or delete data or entire files, cause a 
machine halt, or do some other damage. A striking example of how logic bombs 
can be employed was the case of Tim Lloyd, who was convicted of setting a logic 
bomb that cost his employer, Omega Engineering, more than $10 million, 
derailed its corporate growth strategy, and eventually led to the layoff of 80 
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workers [GAUD00]. Ultimately, Lloyd was sentenced to 41 months in prison and 
ordered to pay $2 million in restitution. 


Trojan Horses 


A Trojan horse! is a useful, or apparently useful, program or command procedure 
containing hidden code that, when invoked, performs some unwanted or harmful 
function. 

Trojan horse programs can be used to accomplish functions indirectly that an 
unauthorized user could not accomplish directly. For example, to gain access to the 
files of another user on a shared system, a user could create a Trojan horse program 
that, when executed, changes the invoking user’s file permissions so that the files are 
readable by any user. The author could then induce users to run the program by 
placing it in a common directory and naming it such that it appears to be a useful 
utility program or application. An example is a program that ostensibly produces a 
listing of the user’s files in a desirable format. After another user has run the 
program, the author of the program can then access the information in the user’s 
files. An example of a Trojan horse program that would be difficult to detect is a 
compiler that has been modified to insert additional code into certain programs as 
they are compiled, such as a system login program [THOMS84]. The code creates a 
backdoor in the login program that permits the author to log on to the system using 
a special password. This Trojan horse can never be discovered by reading the source 
code of the login program. 

Another common motivation for the Trojan horse is data destruction. The 
program appears to be performing a useful function (e.g., a calculator program), but 
it may also be quietly deleting the user’s files. For example, a CBS executive was 
victimized by a Trojan horse that destroyed all information contained in his com- 
puter’s memory [TIME90]. The Trojan horse was implanted in a graphics routine 
offered on an electronic bulletin board system. 

Trojan horses fit into one of three models: 


e Continuing to perform the function of the original program and additionally 
performing a separate malicious activity 


e Continuing to perform the function of the original program but modifying the 
function to perform malicious activity (e.g., a Trojan horse version of a login 
program that collects passwords) or to disguise other malicious activity (e.g., a 
Trojan horse version of a process listing program that does not display certain 
processes that are malicious) 


e Performing a malicious function that completely replaces the function of the 
original program 


'In Greek mythology, the Trojan horse was used by the Greeks during their siege of Troy. Epeios 
constructed a giant hollow wooden horse in which thirty of the most valiant Greek heroes concealed 
themselves. The rest of the Greeks burned their encampment and pretended to sail away but actually hid 
nearby. The Trojans, convinced the horse was a gift and the siege over, dragged the horse into the city. 
That night, the Greeks emerged from the horse and opened the city gates to the Greek army. A blood- 
bath ensued, resulting in the destruction of Troy and the death or enslavement of all its citizens. 
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Mobile Code 


Mobile code refers to programs (e.g., script, macro, or other portable instruction) 
that can be shipped unchanged to a heterogeneous collection of platforms and 
execute with identical semantics [JANSO1]. The term also applies to situations 
involving a large homogeneous collection of platforms (e.g., Microsoft Windows). 
Mobile code is transmitted from a remote system to a local system and then 
executed on the local system without the user’s explicit instruction. Mobile code 
often acts as a mechanism for a virus, worm, or Trojan horse to be transmitted to the 
user’s workstation. In other cases, mobile code takes advantage of vulnerabilities to 
perform its own exploits, such as unauthorized data access or root compromise. 
Popular vehicles for mobile code include Java applets, ActiveX, JavaScript, and 
VBScript. The most common ways of using mobile code for malicious operations on 
local system are cross-site scripting, interactive and dynamic Web sites, e-mail 
attachments, and downloads from untrusted sites or of untrusted software. 


Multiple-Threat Malware 


Viruses and other malware may operate in multiple ways. The terminology is far 
from uniform; this subsection gives a brief introduction to several related concepts 
that could be considered multiple-threat malware. 

A multipartite virus infects in multiple ways. Typically, the multipartite virus is 
capable of infecting multiple types of files, so that virus eradication must deal with 
all of the possible sites of infection. 

A blended attack uses multiple methods of infection or transmission, to maxi- 
mize the speed of contagion and the severity of the attack. Some writers characterize 
a blended attack as a package that includes multiple types of malware. An example of 
a blended attack is the Nimda attack, erroneously referred to as simply a worm. 
Nimda uses four distribution methods: 


e E-mail: A user on a vulnerable host opens an infected e-mail attachment; 
Nimda looks for e-mail addresses on the host and then sends copies of itself to 
those addresses. 


e Windows shares: Nimda scans hosts for unsecured Windows file shares; it can 
then use NetBIOS86 as a transport mechanism to infect files on that host in 
the hopes that a user will run an infected file, which will activate Nimda on 
that host. 


e Web servers: Nimda scans Web servers, looking for known vulnerabilities in 
Microsoft HS. If it finds a vulnerable server, it attempts to transfer a copy of 
itself to the server and infect it and its files. 


© Web clients: If a vulnerable Web client visits a Web server that has been 
infected by Nimda, the client’s workstation will become infected. 


Thus, Nimda has worm, virus, and mobile code characteristics. Blended attacks 
may also spread through other services, such as instant messaging and peer-to-peer 
file sharing. 
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21.2 VIRUSES 


The Nature of Viruses 


A computer virus is a piece of software that can “infect” other programs by modifying 
them; the modification includes injecting the original program with a routine to make 
copies of the virus program, which can then go on to infect other programs. Computer 
viruses first appeared in the early 1980s, and the term itself is attributed to Fred Cohen 
in 1983. Cohen is the author of a groundbreaking book on the subject [COHE94]. 

Biological viruses are tiny scraps of genetic code—DNA or RNA—that can 
take over the machinery of a living cell and trick it into making thousands of flaw- 
less replicas of the original virus. Like its biological counterpart, a computer virus 
carries in its instructional code the recipe for making perfect copies of itself. The 
typical virus becomes embedded in a program on a computer. Then, whenever the 
infected computer comes into contact with an uninfected piece of software, a fresh 
copy of the virus passes into the new program. Thus, the infection can be spread 
from computer to computer by unsuspecting users who either swap disks or send 
programs to one another over a network. In a network environment, the ability to 
access applications and system services on other computers provides a perfect cul- 
ture for the spread of a virus. 

A virus can do anything that other programs do. The difference is that a virus 
attaches itself to another program and executes secretly when the host program is 
run. Once a virus is executing, it can perform any function, such as erasing files and 
programs that is allowed by the privileges of the current user. 

A computer virus has three parts [AYCO06]: 


e Infection mechanism: The means by which a virus spreads, enabling it to repli- 
cate. The mechanism is also referred to as the infection vector. 


e Trigger: The event or condition that determines when the payload is activated 
or delivered. 


e Payload: What the virus does, besides spreading. The payload may involve 
damage or may involve benign but noticeable activity. 


During its lifetime, a typical virus goes through the following four phases: 


e Dormant phase: The virus is idle. The virus will eventually be activated by 
some event, such as a date, the presence of another program or file, or the 
capacity of the disk exceeding some limit. Not all viruses have this stage. 


e Propagation phase: The virus places a copy of itself into other programs or into 
certain system areas on the disk. The copy may not be identical to the propa- 
gating version; viruses often morph to evade detection. Each infected program 
will now contain a clone of the virus, which will itself enter a propagation phase. 


e Triggering phase: The virus is activated to perform the function for which it 
was intended. As with the dormant phase, the triggering phase can be caused 
by a variety of system events, including a count of the number of times that 
this copy of the virus has made copies of itself. 
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e Execution phase: The function is performed. The function may be harmless, 
such as a message on the screen, or damaging, such as the destruction of 
programs and data files. 


Most viruses carry out their work in a manner that is specific to a particular oper- 
ating system and, in some cases, specific to a particular hardware platform. Thus, they 
are designed to take advantage of the details and weaknesses of particular systems. 


Virus STRUCTURE A virus can be prepended or postpended to an executable 
program, or it can be embedded in some other fashion. The key to its operation is 
that the infected program, when invoked, will first execute the virus code and then 
execute the original code of the program. 

A very general depiction of virus structure is shown in Figure 21.1 (based on 
[COHE94]). In this case, the virus code, V, is prepended to infected programs, and it 
is assumed that the entry point to the program, when invoked, is the first line of the 
program. 

The infected program begins with the virus code and works as follows. The first 
line of code is a jump to the main virus program. The second line is a special marker 
that is used by the virus to determine whether or not a potential victim program has 
already been infected with this virus. When the program is invoked, control is imme- 
diately transferred to the main virus program. The virus program may first seek out 
uninfected executable files and infect them. Next, the virus may perform some 
action, usually detrimental to the system. This action could be performed every time 
the program is invoked, or it could be a logic bomb that triggers only under certain 
conditions. Finally, the virus transfers control to the original program. If the infection 


program V := 


{goto main; 
1234567; 


subroutine infect-executable := 
{loop: 
file := get-random-executable-file; 
if (first-line-of-file = 1234567) 
then goto loop 
else prepend V to file; } 


subroutine do-damage := 
{whatever damage is to be done} 


subroutine trigger-pulled := 
{return true if some condition holds} 


main: main-program := 
{infect-executable; 
if trigger-pulled then do-damage; 
goto next;} 

next: 


} 


Figure 21.1 A Simple Virus 


21.2 /VIRUSES 21-9 


program CV := 


{goto main; 
01234567; 


subroutine infect-executable := 
{loop: 
file := get-random-executable-file; 
if (first-line-of-file = 01234567) then goto loop; 
(1) compress file; 
(2) prepend CV to file; 
} 


main: main-program := 
{if ask-permission then infect-executable; 
(3) uncompress rest-of-file; 
(4) run uncompressed file; } 


} 


Figure 21.2 Logic for a Compression Virus 


phase of the program is reasonably rapid, a user is unlikely to notice any difference 
between the execution of an infected and an uninfected program. 

A virus such as the one just described is easily detected because an infected 
version of a program is longer than the corresponding uninfected one. A way to 
thwart such a simple means of detecting a virus is to compress the executable file so 
that both the infected and uninfected versions are of identical length. Figure 21.2 
[COHE494] shows in general terms the logic required. The key lines in this virus are 
numbered, and Figure 21.3 [COHE94] illustrates the operation. We assume that 
program P1 is infected with the virus CV. When this program is invoked, control 
passes to its virus, which performs the following steps: 


1. For each uninfected file Pz that is found, the virus first compresses that file to 
produce P4, which is shorter than the original program by the size of the virus. 


2. A copy of the virus is prepended to the compressed program. 


io) 
. 


The compressed version of the original infected program, P}, is uncompressed. 


> 


The uncompressed original program is executed. 


to 


Figure 21.3. A Compression Virus 
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In this example, the virus does nothing other than propagate. As previously 
mentioned, the virus may include a logic bomb. 


INITIAL INFECTION Once a virus has gained entry to a system by infecting a single 
program, it is in a position to potentially infect some or all other executable files on 
that system when the infected program executes. Thus, viral infection can be 
completely prevented by preventing the virus from gaining entry in the first place. 
Unfortunately, prevention is extraordinarily difficult because a virus can be part of 
any program outside a system. Thus, unless one is content to take an absolutely bare 
piece of iron and write all one’s own system and application programs, one is 
vulnerable. Many forms of infection can also be blocked by denying normal users 
the right to modify programs on the system. 

The lack of access controls on early PCs is a key reason why traditional 
machine code based viruses spread rapidly on these systems. In contrast, while it is 
easy enough to write a machine code virus for UNIX systems, they were almost 
never seen in practice because the existence of access controls on these systems pre- 
vented effective propagation of the virus. Traditional machine code based viruses 
are now less prevalent, because modern PC OSs do have more effective access con- 
trols. However, virus creators have found other avenues, such as macro and e-mail 
viruses, as discussed subsequently. 


Viruses Classification 


There has been a continuous arms race between virus writers and writers of 
antivirus software since viruses first appeared. As effective countermeasures are 
developed for existing types of viruses, newer types are developed. There is no 
simple or universally agreed upon classification scheme for viruses, In this section, 
we follow [AYCO06] and classify viruses along two orthogonal axes: the type of 
target the virus tries to infect and the method the virus uses to conceal itself from 
detection by users and antivirus software. 
A virus classification by target includes the following categories: 


¢ Boot sector infector: Infects a master boot record or boot record and spreads 
when a system is booted from the disk containing the virus. 


e File infector: Infects files that the operating system or shell consider to be 
executable. 


e Macro virus: Infects files with macro code that is interpreted by an applica- 
tion. 


A virus classification by concealment strategy includes the following categories: 


e Encrypted virus: A typical approach is as follows. A portion of the virus cre- 
ates arandom encryption key and encrypts the remainder of the virus. The key 
is stored with the virus. When an infected program is invoked, the virus uses 
the stored random key to decrypt the virus. When the virus replicates, a differ- 
ent random key is selected. Because the bulk of the virus is encrypted with a 
different key for each instance, there is no constant bit pattern to observe. 
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e Stealth virus: A form of virus explicitly designed to hide itself from detection 
by antivirus software. Thus, the entire virus, not just a payload is hidden. 


e Polymorphic virus: A virus that mutates with every infection, making detec- 
tion by the “signature” of the virus impossible. 


e Metamorphic virus: As with a polymorphic virus, a metamorphic virus mutates 
with every infection. The difference is that a metamorphic virus rewrites itself 
completely at each iteration, increasing the difficulty of detection. 
Metamorphic viruses may change their behavior as well as their appearance. 


One example of a stealth virus was discussed earlier: a virus that uses com- 
pression so that the infected program is exactly the same length as an uninfected 
version. Far more sophisticated techniques are possible. For example, a virus can 
place intercept logic in disk I/O routines, so that when there is an attempt to read 
suspected portions of the disk using these routines, the virus will present back the 
original, uninfected program. Thus, stealth is not a term that applies to a virus as such 
but, rather, refers to a technique used by a virus to evade detection. 

A polymorphic virus creates copies during replication that are functionally 
equivalent but have distinctly different bit patterns. As with a stealth virus, the pur- 
pose is to defeat programs that scan for viruses. In this case, the “signature” of the 
virus will vary with each copy. To achieve this variation, the virus may randomly 
insert superfluous instructions or interchange the order of independent instructions. 
A more effective approach is to use encryption. The strategy of the encryption virus 
is followed. The portion of the virus that is responsible for generating keys and 
performing encryption/decryption is referred to as the mutation engine. The muta- 
tion engine itself is altered with each use. 


Virus Kits 


Another weapon in the virus writers’ armory is the virus-creation toolkit. Such a 
toolkit enables a relative novice to quickly create a number of different viruses. 
Although viruses created with toolkits tend to be less sophisticated than viruses 
designed from scratch, the sheer number of new viruses that can be generated using 
a toolkit creates a problem for antivirus schemes. 


Macro Viruses 


In the mid-1990s, macro viruses became by far the most prevalent type of virus. 
Macro viruses are particularly threatening for a number of reasons: 


1. A macro virus is platform independent. Many macro viruses infect Microsoft 
Word documents or other Microsoft Office documents. Any hardware plat- 
form and operating system that supports these applications can be infected. 
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. Macro viruses infect documents, not executable portions of code. Most of the 
information introduced onto a computer system is in the form of a document 
rather than a program. 


3. Macro viruses are easily spread. A very common method is by electronic mail. 


4, Because macro viruses infect user documents rather than system programs, tra- 
ditional file system access controls are of limited use in preventing their spread. 
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Macro viruses take advantage of a feature found in Word and other office 
applications such as Microsoft Excel, namely the macro. In essence, a macro is an 
executable program embedded in a word processing document or other type of file. 
Typically, users employ macros to automate repetitive tasks and thereby save 
keystrokes. The macro language is usually some form of the Basic programming 
language. A user might define a sequence of keystrokes in a macro and set it up so 
that the macro is invoked when a function key or special short combination of keys 
is input. 

Successive releases of MS Office products provide increased protection 
against macro viruses. For example, Microsoft offers an optional Macro Virus 
Protection tool that detects suspicious Word files and alerts the customer to the 
potential risk of opening a file with macros. Various antivirus product vendors have 
also developed tools to detect and correct macro viruses. As in other types of 
viruses, the arms race continues in the field of macro viruses, but they no longer are 
the predominant virus threat. 


E-Mail Viruses 


A more recent development in malicious software is the e-mail virus. The first 
rapidly spreading e-mail viruses, such as Melissa, made use of a Microsoft Word 
macro embedded in an attachment. If the recipient opens the e-mail attachment, the 
Word macro is activated. Then 


1. The e-mail virus sends itself to everyone on the mailing list in the user’s e-mail 
package. 


2. The virus does local damage on the user’s system. 


In 1999, a more powerful version of the e-mail virus appeared. This newer 
version can be activated merely by opening an e-mail that contains the virus rather 
than opening an attachment. The virus uses the Visual Basic scripting language 
supported by the e-mail package. 

Thus we see a new generation of malware that arrives via e-mail and uses e-mail 
software features to replicate itself across the Internet. The virus propagates itself as 
soon as it is activated (either by opening an e-mail attachment or by opening the 
e-mail) to all of the e-mail addresses known to the infected host. As a result, whereas 
viruses used to take months or years to propagate, they now do so in hours. This makes 
it very difficult for antivirus software to respond before much damage is done. 
Ultimately, a greater degree of security must be built into Internet utility and applica- 
tion software on PCs to counter the growing threat. 


21.3 VIRUS COUNTERMEASURES 


Antivirus Approaches 


The ideal solution to the threat of viruses is prevention: Do not allow a virus to get 
into the system in the first place, or block the ability of a virus to modify any files 
containing executable code or macros. This goal is, in general, impossible to achieve, 
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although prevention can reduce the number of successful viral attacks. The next best 
approach is to be able to do the following: 


e Detection: Once the infection has occurred, determine that it has occurred 
and locate the virus. 


e Identification: Once detection has been achieved, identify the specific virus 
that has infected a program. 


e Removal: Once the specific virus has been identified, remove all traces of the 
virus from the infected program and restore it to its original state. Remove the 
virus from all infected systems so that the virus cannot spread further. 


If detection succeeds but either identification or removal is not possible, then the 
alternative is to discard the infected file and reload a clean backup version. 

Advances in virus and antivirus technology go hand in hand. Early viruses 
were relatively simple code fragments and could be identified and purged with 
relatively simple antivirus software packages. As the virus arms race has evolved, 
both viruses and, necessarily, antivirus software have grown more complex and 
sophisticated. 

[STEP93] identifies four generations of antivirus software: 


e First generation: simple scanners 
e Second generation: heuristic scanners 
e Third generation: activity traps 


e Fourth generation: full-featured protection 


A first-generation scanner requires a virus signature to identify a virus. The 
virus may contain “wildcards” but has essentially the same structure and bit pattern 
in all copies. Such signature-specific scanners are limited to the detection of known 
viruses. Another type of first-generation scanner maintains a record of the length of 
programs and looks for changes in length. 

A second-generation scanner does not rely on a specific signature. Rather, the 
scanner uses heuristic rules to search for probable virus infection. One class of such 
scanners looks for fragments of code that are often associated with viruses. For 
example, a scanner may look for the beginning of an encryption loop used in a poly- 
morphic virus and discover the encryption key. Once the key is discovered, the 
scanner can decrypt the virus to identify it, then remove the infection and return 
the program to service. 

Another second-generation approach is integrity checking. A checksum can 
be appended to each program. If a virus infects the program without changing the 
checksum, then an integrity check will catch the change. To counter a virus that is 
sophisticated enough to change the checksum when it infects a program, an 
encrypted hash function can be used. The encryption key is stored separately from 
the program so that the virus cannot generate a new hash code and encrypt that. By 
using a hash function rather than a simpler checksum, the virus is prevented from 
adjusting the program to produce the same hash code as before. 

Third-generation programs are memory-resident programs that identify a 
virus by its actions rather than its structure in an infected program. Such programs 


21-14 CHAPTER 21 / MALICIOUS SOFTWARE 


have the advantage that it is not necessary to develop signatures and heuristics for a 
wide array of viruses. Rather, it is necessary only to identify the small set of actions 
that indicate an infection is being attempted and then to intervene. 

Fourth-generation products are packages consisting of a variety of antivirus 
techniques used in conjunction. These include scanning and activity trap compo- 
nents. In addition, such a package includes access control capability, which limits the 
ability of viruses to penetrate a system and then limits the ability of a virus to update 
files in order to pass on the infection. 

The arms race continues. With fourth-generation packages, a more compre- 
hensive defense strategy is employed, broadening the scope of defense to more 
general-purpose computer security measures. 


Advanced Antivirus Techniques 


More sophisticated antivirus approaches and products continue to appear. In this 
subsection, we highlight some of the most important. 


GENERIC DECRYPTION Generic decryption (GD) technology enables the antivirus 
program to easily detect even the most complex polymorphic viruses while 
maintaining fast scanning speeds [NACH97]. Recall that when a file containing a 
polymorphic virus is executed, the virus must decrypt itself to activate. In order to 
detect such a structure, executable files are run through a GD scanner, which 
contains the following elements: 


e CPU emulator: A software-based virtual computer. Instructions in an exe- 
cutable file are interpreted by the emulator rather than executed on the 
underlying processor. The emulator includes software versions of all registers 
and other processor hardware, so that the underlying processor is unaffected 
by programs interpreted on the emulator. 


e Virus signature scanner: A module that scans the target code looking for 
known virus signatures. 


e Emulation control module: Controls the execution of the target code. 


At the start of each simulation, the emulator begins interpreting instructions 
in the target code, one at a time. Thus, if the code includes a decryption routine that 
decrypts and hence exposes the virus, that code is interpreted. In effect, the virus 
does the work for the antivirus program by exposing the virus. Periodically, the con- 
trol module interrupts interpretation to scan the target code for virus signatures. 

During interpretation, the target code can cause no damage to the actual per- 
sonal computer environment, because it is being interpreted in a completely con- 
trolled environment. 

The most difficult design issue with a GD scanner is to determine how long to 
run each interpretation. Typically, virus elements are activated soon after a program 
begins executing, but this need not be the case. The longer the scanner emulates a 
particular program, the more likely it is to catch any hidden viruses. However, the 
antivirus program can take up only a limited amount of time and resources before 
users complain of degraded system performance. 
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DicitAL Immune System The digital immune system is a comprehensive approach 
to virus protection developed by IBM [KEPH97a, KEPH97b, WHIT99] and 
subsequently refined by Symantec [SYMA01]. The motivation for this development 
has been the rising threat of Internet-based virus propagation. We first say a few 
words about this threat and then summarize IBM’s approach. 

Traditionally, the virus threat was characterized by the relatively slow spread of 
new viruses and new mutations. Antivirus software was typically updated on a 
monthly basis, and this was sufficient to control the problem. Also traditionally, the 
Internet played a comparatively small role in the spread of viruses. But as [CHES97] 
points out, two major trends in Internet technology have had an increasing impact on 
the rate of virus propagation in recent years: 


e Integrated mail systems: Systems such as Lotus Notes and Microsoft Outlook 
make it very simple to send anything to anyone and to work with objects that 
are received. 


e Mobile-program systems: Capabilities such as Java and ActiveX allow 
programs to move on their own from one system to another. 


In response to the threat posed by these Internet-based capabilities, IBM has 
developed a prototype digital immune system. This system expands on the use of 
program emulation discussed in the preceding subsection and provides a general- 
purpose emulation and virus-detection system. The objective of this system is to 
provide rapid response time so that viruses can be stamped out almost as soon as 
they are introduced. When a new virus enters an organization, the immune system 
automatically captures it, analyzes it, adds detection and shielding for it, removes it, 
and passes information about that virus to systems running IBM AntiVirus so that it 
can be detected before it is allowed to run elsewhere. 

Figure 21.4 illustrates the typical steps in digital immune system operation: 


1. A monitoring program on each PC uses a variety of heuristics based on system 
behavior, suspicious changes to programs, or family signature to infer that a 
virus may be present. The monitoring program forwards a copy of any program 
thought to be infected to an administrative machine within the organization. 
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The administrative machine encrypts the sample and sends it to a central virus 
analysis machine. 


3. This machine creates an environment in which the infected program can be 
safely run for analysis. Techniques used for this purpose include emulation, or the 
creation of a protected environment within which the suspect program can be 
executed and monitored. The virus analysis machine then produces a prescrip- 
tion for identifying and removing the virus. 


4. The resulting prescription is sent back to the administrative machine. 


mn 
. 


The administrative machine forwards the prescription to the infected client. 
6. The prescription is also forwarded to other clients in the organization. 


7. Subscribers around the world receive regular antivirus updates that protect 
them from the new virus. 
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Figure 21.4 Digital Immune System 


The success of the digital immune system depends on the ability of the virus 
analysis machine to detect new and innovative virus strains. By constantly analyzing 
and monitoring the viruses found in the wild, it should be possible to continually 
update the digital immune software to keep up with the threat. 


BEHAVIOR-BLOCKING Sorrware Unlike heuristics or fingerprint-based scanners, 
behavior-blocking software integrates with the operating system of a host computer 
and monitors program behavior in real-time for malicious actions [CONRO2, 
NACH02]. The behavior blocking software then blocks potentially malicious actions 
before they have a chance to affect the system. Monitored behaviors can include 


e Attempts to open, view, delete, and/or modify files; 

e Attempts to format disk drives and other unrecoverable disk operations; 

e Modifications to the logic of executable files or macros; 

e Modification of critical system settings, such as start-up settings; 

e Scripting of e-mail and instant messaging clients to send executable content; and 


e Initiation of network communications. 


Figure 21.5 illustrates the operation of a behavior blocker. Behavior-blocking 
software runs on server and desktop computers and is instructed through policies 
set by the network administrator to let benign actions take place but to intercede 
when unauthorized or suspicious actions occur. The module blocks any suspicious 
software from executing. A blocker isolates the code in a sandbox, which restricts 
the code’s access to various OS resources and applications. The blocker then sends 
an alert. 

Because a behavior blocker can block suspicious software in real-time, it has an 
advantage over such established antivirus detection techniques as fingerprinting or 
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Figure 21.5 Behavior-Blocking Software Operation 


heuristics. While there are literally trillions of different ways to obfuscate and 
rearrange the instructions of a virus or worm, many of which will evade detection by a 
fingerprint scanner or heuristic, eventually malicious code must make a well-defined 
request to the operating system. Given that the behavior blocker can intercept all such 
requests, it can identify and block malicious actions regardless of how obfuscated the 
program logic appears to be. 

Behavior blocking alone has limitations. Because the malicious code must run 
on the target machine before all its behaviors can be identified, it can cause harm 
before it has been detected and blocked. For example, a new virus might shuffle a 
number of seemingly unimportant files around the hard drive before infecting a sin- 
gle file and being blocked. Even though the actual infection was blocked, the user 
may be unable to locate his or her files, causing a loss to productivity or possibly 
worse. 


21.4 WORMS 


A worm is a program that can replicate itself and send copies from computer to 
computer across network connections. Upon arrival, the worm may be activated to 
replicate and propagate again. In addition to propagation, the worm usually 
performs some unwanted function. An e-mail virus has some of the characteristics 
of a worm because it propagates itself from system to system. However, we can still 
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classify it as a virus because it uses a document modified to contain viral macro 
content and requires human action. A worm actively seeks out more machines to 
infect and each machine that is infected serves as an automated launching pad for 
attacks on other machines. 

The concept of a computer worm was introduced in John Brunner’s 1975 SF 
novel The Shockwave Rider. The first known worm implementation was done in 
Xerox Palo Alto Labs in the early 1980s. It was nonmalicious, searching for idle 
systems to use to run a computationally intensive task. 

Network worm programs use network connections to spread from system to 
system. Once active within a system, a network worm can behave as a computer 
virus or bacteria, or it could implant Trojan horse programs or perform any number 
of disruptive or destructive actions. 

To replicate itself, a network worm uses some sort of network vehicle. 
Examples include the following: 


e Electronic mail facility: A worm mails a copy of itself to other systems, so that 
its code is run when the e-mail or an attachment is received or viewed. 


e Remote execution capability: A worm executes a copy of itself on another 
system, either using an explicit remote execution facility or by exploiting a 
program flaw in a network service to subvert its operations. 


e Remote login capability: A worm logs onto a remote system as a user and then 
uses commands to copy itself from one system to the other, where it then 
executes. 


The new copy of the worm program is then run on the remote system where, in 
addition to any functions that it performs at that system, it continues to spread in the 
same fashion. 

A network worm exhibits the same characteristics as a computer virus: a 
dormant phase, a propagation phase, a triggering phase, and an execution phase. The 
propagation phase generally performs the following functions: 


1. Search for other systems to infect by examining host tables or similar reposi- 
tories of remote system addresses. 


2. Establish a connection with a remote system. 


- 


Copy itself to the remote system and cause the copy to be run. 


The network worm may also attempt to determine whether a system has 
previously been infected before copying itself to the system. In a multiprogramming 
system, it may also disguise its presence by naming itself as a system process or using 
some other name that may not be noticed by a system operator. 

As with viruses, network worms are difficult to counter. 


The Morris Worm 


Until the current generation of worms, the best known was the worm released onto 
the Internet by Robert Morris in 1988 [ORMA03]. The Morris worm was designed to 
spread on UNIX systems and used a number of different techniques for propagation. 
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When a copy began execution, its first task was to discover other hosts known to this 
host that would allow entry from this host. The worm performed this task by examin- 
ing a variety of lists and tables, including system tables that declared which other 
machines were trusted by this host, users’ mail forwarding files, tables by which users 
gave themselves permission for access to remote accounts, and from a program that 
reported the status of network connections. For each discovered host, the worm tried 
a number of methods for gaining access: 


1. It attempted to log on to a remote host as a legitimate user. In this method, the 
worm first attempted to crack the local password file and then used the 
discovered passwords and corresponding user IDs. The assumption was that 
many users would use the same password on different systems. To obtain the 
passwords, the worm ran a password-cracking program that tried 


a. Each user’s account name and simple permutations of it 


b. A list of 432 built-in passwords that Morris thought to be likely 
candidates” 


c. All the words in the local system dictionary 


N 


. It exploited a bug in the UNIX finger protocol, which reports the whereabouts of 
a remote user. 


3. It exploited a trapdoor in the debug option of the remote process that receives 
and sends mail. 


If any of these attacks succeeded, the worm achieved communication with the 
operating system command interpreter. It then sent this interpreter a short boot- 
strap program, issued a command to execute that program, and then logged off. The 
bootstrap program then called back the parent program and downloaded the 
remainder of the worm. The new worm was then executed. 


Worm Propagation Model 


[ZOU0DS] describes a model for worm propagation based on an analysis of recent 
worm attacks. The speed of propagation and the total number of hosts infected 
depend on a number of factors, including the mode of propagation, the vulnerability 
or vulnerabilities exploited, and the degree of similarity to preceding attacks. For 
the latter factor, an attack that is a variation of a recent previous attack may be 
countered more effectively than a more novel attack. Figure 21.6 shows the dynam- 
ics for one typical set of parameters. Propagation proceeds through three phases. In 
the initial phase, the number of hosts increases exponentially. To see that this is so, 
consider a simplified case in which a worm is launched from a single host and infects 
two nearby hosts. Each of these hosts infects two more hosts, and so on. This results 
in exponential growth. After a time, infecting hosts waste some time attacking 
already infected hosts, which reduces the rate of infection. During this middle phase, 
growth is approximately linear, but the rate of infection is rapid. When most vulner- 
able computers have been infected, the attack enters a slow finish phase as the 
worm seeks out those remaining hosts that are difficult to identify. 


The complete list is provided at this book’s Web site. 
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Figure 21.6 Worm Propagation Model 


Clearly, the objective in countering a worm is to catch the worm in its slow 
start phase, at a time when few hosts have been infected. 


Recent Worm Attacks 


The contemporary era of worm threats began with the release of the Code Red 
worm in July of 2001. Code Red exploits a security hole in the Microsoft Internet 
Information Server (IIS) to penetrate and spread. It also disables the system file 
checker in Windows. The worm probes random IP addresses to spread to other hosts. 
During a certain period of time, it only spreads. It then initiates a denial-of-service 
attack against a government Web site by flooding the site with packets from numer- 
ous hosts. The worm then suspends activities and reactivates periodically. In the 
second wave of attack, Code Red infected nearly 360,000 servers in 14 hours. In addi- 
tion to the havoc it caused at the targeted server, Code Red consumed enormous 
amounts of Internet capacity, disrupting service. 

Code Red II is a variant that targets Microsoft IISs. In addition, this newer 
worm installs a backdoor, allowing a hacker to remotely execute commands on 
victim computers. 

In early 2003, the SOL Slammer worm appeared. This worm exploited a buffer 
overflow vulnerability in Microsoft SQL server. The Slammer was extremely com- 
pact and spread rapidly, infecting 90% of vulnerable hosts within 10 minutes. Late 
2003 saw the arrival of the Sobig.f worm, which exploited open proxy servers to turn 
infected machines into spam engines. At its peak, Sobig.f reportedly accounted for 
one in every 17 messages and produced more than one million copies of itself within 
the first 24 hours. 
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Mydoom is a mass-mailing e-mail worm that appeared in 2004. It followed a 
growing trend of installing a backdoor in infected computers, thereby enabling 
hackers to gain remote access to data such as passwords and credit card numbers. 
Mydoom replicated up to 1000 times per minute and reportedly flooded the 
Internet with 100 million infected messages in 36 hours. 

A recent worm that rapidly became prevalent in a variety of versions is the 
Warezov family of worms [KIRK06]. When the worm is launched, it creates several 
executable in system directories and sets itself to run every time Windows starts, by 
creating a registry entry. Warezov scans several types of files for e-mail addresses 
and sends itself as an e-mail attachment. Some variants are capable of downloading 
other malware, such as Trojan horses and adware. Many variants disable security 
related products and/or disable their updating capability. 


State of Worm Technology 
The state of the art in worm technology includes the following: 


e Multiplatform: Newer worms are not limited to Windows machines but can 
attack a variety of platforms, especially the popular varieties of UNIX. 


e Multi-exploit: New worms penetrate systems in a variety of ways, using 
exploits against Web servers, browsers, e-mail, file sharing, and other network- 
based applications. 


e Ultrafast spreading: One technique to accelerate the spread of a worm is to 
conduct a prior Internet scan to accumulate Internet addresses of vulnerable 
machines. 


e Polymorphic: To evade detection, skip past filters, and foil real-time analysis, 
worms adopt the virus polymorphic technique. Each copy of the worm has 
new code generated on the fly using functionally equivalent instructions and 
encryption techniques. 


e Metamorphic: In addition to changing their appearance, metamorphic worms 
have a repertoire of behavior patterns that are unleashed at different stages of 
propagation. 

e Transport vehicles: Because worms can rapidly compromise a large number of 
systems, they are ideal for spreading other distributed attack tools, such as 
distributed denial of service bots. 


e Zero-day exploit: To achieve maximum surprise and distribution, a worm 
should exploit an unknown vulnerability that is only discovered by the general 
network community when the worm is launched. 


Mobile Phone Worms 


Worms first appeared on mobile phones in 2004. These worms communicate 
through Bluetooth wireless connections or via the multimedia messaging service 
(MMS). The target is the smartphone, which is a mobile phone that permits users to 
install software applications from sources other than the cellular network operator. 
Mobile phone malware can completely disable the phone, delete data on the phone, 
or force the device to send costly messages to premium-priced numbers. 
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An example of a mobile phone worm is CommWarrior, which was launched in 
2005. This worm replicates by means of Bluetooth to other phones in the receiving 
area. It also sends itself as an MMS file to numbers in the phone’s address book and 
in automatic replies to incoming text messages and MMS messages. In addition, it 
copies itself to the removable memory card and inserts itself into the program 
installation files on the phone. 


Worm Countermeasures 


There is considerable overlap in techniques for dealing with viruses and worms. 
Once a worm is resident on a machine, antivirus software can be used to detect it. In 
addition, because worm propagation generates considerable network activity, net- 
work activity and usage monitoring can form the basis of a worm defense. 

To begin, let us consider the requirements for an effective worm countermea- 
sure scheme: 


e Generality: The approach taken should be able to handle a wide variety of 
worm attacks, including polymorphic worms. 


e Timeliness: The approach should respond quickly so as to limit the number of 
infected systems and the number of generated transmissions from infected 
systems. 


¢ Resiliency: The approach should be resistant to evasion techniques employed 
by attackers to evade worm countermeasures. 


e Minimal denial-of-service costs: The approach should result in minimal reduc- 
tion in capacity or service due to the actions of the countermeasure software. 
That is, in an attempt to contain worm propagation, the countermeasure 
should not significantly disrupt normal operation. 


e Transparency: The countermeasure software and devices should not require 
modification to existing (legacy) OSs, application software, and hardware. 


¢ Global and local coverage: The approach should be able to deal with attack 
sources both from outside and inside the enterprise network. 


No existing worm countermeasure scheme appears to satisfy all these require- 
ments. Thus, administrators typically need to use multiple approaches in defending 
against worm attacks. 


COUNTERMEASURE APPROACHES Following [JHI07], we list six classes of worm 
defense: 


A. Signature-based worm scan filtering: This type of approach generates a worm 
signature, which is then used to prevent worm scans from entering/leaving a 
network/host. Typically, this approach involves identifying suspicious flows 
and generating a worm signature. This approach is vulnerable to the use of 
polymorphic worms: Either the detection software misses the worm or, if it is 
sufficiently sophisticated to deal with polymorphic worms, the scheme may 
take a long time to react. [NEWSO0S5] is an example of this approach. 


b. Filter-based worm containment: This approach is similar to class A but focuses 
on worm content rather than a scan signature. The filter checks a message to 
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determine if it contains worm code. An example is Vigilante [COST0S5], which 
relies on collaborative worm detection at end hosts. This approach can be quite 
effective but requires efficient detection algorithms and rapid alert dissemination. 


C. Payload-classification-based worm containment: These network-based tech- 
niques examine packets to see if they contain a worm. Various anomaly detection 
techniques can be used, but care is needed to avoid high levels of false positives 
or negatives. An example of this approach is reported in [CHINOS5], which looks 
for exploit code in network flows. This approach does not generate signatures 
based on byte patterns but rather looks for control and data flow structures that 
suggest an exploit. 


D. Threshold random walk (TRW) scan detection: TRW exploits randomness 
in picking destinations to connect to as a way of detecting if a scanner is in 
operation [JUNG04]. TRW is suitable for deployment in high-speed, low-cost 
network devices. It is effective against the common behavior seen in worm 
scans. 


E. Rate limiting: This class limits the rate of scanlike traffic from an infected host. 
Various strategies can be used, including limiting the number of new machines a 
host can connect to in a window of time, detecting a high connection failure rate, 
and limiting the number of unique IP addresses a host can scan in a window of 
time. [CHEN04] is an example. This class of countermeasures may introduce 
longer delays for normal traffic. This class is also not suited for slow, stealthy 
worms that spread slowly to avoid detection based on activity level. 


FE. Rate halting: This approach immediately blocks outgoing traffic when a 
threshold is exceeded either in outgoing connection rate or diversity of con- 
nection attempts [JHI07]. The approach must include measures to quickly 
unblock mistakenly blocked hosts in a transparent way. Rate halting can inte- 
grate with a signature- or filter-based approach so that once a signature or fil- 
ter is generated, every blocked host can be unblocked. Rate halting appears to 
offer a very effective countermeasure. As with rate limiting, rate halting tech- 
niques are not suitable for slow, stealthy worms. 


We look now at two approaches in more detail. 


PROACTIVE WORM CONTAINMENT The PWC scheme [JHI07] is host based rather 
than being based on network devices such as honeypots, firewalls, and network 
IDSs. PWC is designed to address the threat of worms that spread rapidly. The 
software on a host looks for surges in the rate of frequency of outgoing connection 
attempts and the diversity of connections to remote hosts. When such a surge is 
detected, the software immediately blocks its host from further connection 
attempts. The developers estimate that only a few dozen infected packets may be 
sent out to other systems before PWC quarantines that attack. In contrast, the 
Slammer worm on average sent out 4000 infected packets per second. 

A deployed PWC system consists of a PWC manager and PWC agents in 
hosts. Figure 21.7 is an example of an architecture that includes PWC. In this exam- 
ple, the security manager, signature extractor, and PWC manager are implemented 
in a single network device. In practice, these three modules could be implemented as 
two or three separate devices. 
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Figure 21.7 Example PWC Deployment 


The operation of the PWC architecture can be described as follows: 


A. A PWC agent monitors outgoing traffic for scan activity, determined by a 
surge in UDP or TCP connection attempts to remote hosts. If a surge is 
detected, the agent performs the following actions: (1) issues an alert to local 
system; (2) blocks all outgoing connection attempts; (3) transmits the alert to 
the PWC manager; and (4) starts a relaxation analysis, described in D. 


B. A PWC manager receives an alert. The PWC propagates the alert to all other 
agents (beside the originating agent). 

C. The host receives an alert. The agent must decide whether to ignore the alert, in 
the following way. If the time since the last incoming packet has been sufficiently 
long so that the agent would have detected a worm if infected, then the alert is 
ignored. Otherwise, the agent assumes that it might be infected and performs the 
following actions: (1) blocks all outgoing connection attempts from the specific 
alerting port; and (2) starts a relaxation analysis, described in D. 


D. Relaxation analysis is performed as follows. An agent monitors outgoing activ- 
ity for a fixed window of time to see if outgoing connections exceed a thresh- 
old. If so, blockage is continued and relaxation analysis is performed for 
another window of time. This process continues until the outgoing connection 
rate drops below the threshold, at which time the agent removes the block. If 
the threshold continues to be exceeded over a sufficient number of relaxation 
windows, the agent isolates the host and reports to the PWC manager. 
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Meanwhile, a separate aspect of the worm defense system is in operation. The 
signature extractor functions as a passive sensor that monitors all traffic and 
attempts to detect worms by signature analysis. When a new worm is detected, its 
signature is sent by the security manager to the firewall to filter out any more copies 
of the worm. In addition, the PWC manager sends the signature to PWC agents, 
enabling them to immediately recognize infection and disable the worm. 


NETWORK-BASED Worm DEFENSE The key element of a network-based worm 
defense is worm monitoring software. Consider an enterprise network at a site, 
consisting of one or an interconnected set of LANs. Two types of monitoring 
software are needed: 


e Ingress monitors: These are located at the border between the enterprise net- 
work and the Internet. They can be part of the ingress filtering software of a bor- 
der router or external firewall or a separate passive monitor. A honeypot can 
also capture incoming worm traffic. An example of a detection technique for an 
ingress monitor is to look for incoming traffic to unused local IP addresses. 


e Egress monitors: These can be located at the egress point of individual LANs 
on the enterprise network as well as at the border between the enterprise net- 
work and the Internet. In the former case, the egress monitor can be part of 
the egress filtering software of a LAN router or switch. As with ingress moni- 
tors, the external firewall or a honeypot can house the monitoring software. 
Indeed, the two types of monitors can be collocated. The egress monitor is 
designed to catch the source of a worm attack by monitoring outgoing traffic 
for signs of scanning or other suspicious behavior. 


Worm monitors can act in the manner of intrusion detection systems and gen- 
erate alerts to a central administrative system. It is also possible to implement a sys- 
tem that attempts to react in real time to a worm attack, so as to counter zero-day 
exploits effectively. This is similar to the approach taken with the digital immune 
system (Figure 21.4). 

Figure 21.8 shows an example of a worm countermeasure architecture [SIDIOS5]. 
The system works as follows (numbers in figure refer to numbers in the following list): 


1. Sensors deployed at various network locations detect a potential worm. The 
sensor logic can also be incorporated in IDS sensors. 


nN 


The sensors send alerts to a central server that correlates and analyzes the incom- 
ing alerts. The correlation server determines the likelihood that a worm attack is 
being observed and the key characteristics of the attack. 


3. The server forwards its information to a protected environment, where the 
potential worm may be sandboxed for analysis and testing. 


4. The protected system tests the suspicious software against an appropriately 
instrumented version of the targeted application to identify the vulnerability. 


Nn 


The protected system generates one or more software patches and tests these. 


6. If the patch is not susceptible to the infection and does not compromise the 
application’s functionality, the system sends the patch to the application host 
to update the targeted application. 
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Figure 21.8 Placement of Worm Monitors 


The success of such an automated patching system depends on maintaining a 
current list of potential attacks and developing general tools for patching software 
to counter such attacks. Examples of approaches are as follows: 


e Increasing the size of buffers 


e Using minor code-randomization techniques [BHATO03] so that the infection 
no longer works because the code to be attacked is no longer in the same form 
and location 


e Adding filters to the application that enable it to recognize and ignore an attack 


21.5 DISTRIBUTED DENIAL OF SERVICE ATTACKS 


Distributed denial of service (DDoS) attacks present a significant security threat to 
corporations, and the threat appears to be growing [VIJA02]. In one study, covering 
a three-week period in 2001, investigators observed more than 12,000 attacks 
against more than 5000 distinct targets, ranging from well-known ecommerce com- 
panies such as Amazon and Hotmail to small foreign ISPs and dial-up connections 
[MOOR01]. DDoS attacks make computer systems inaccessible by flooding servers, 
networks, or even end user systems with useless traffic so that legitimate users can 
no longer gain access to those resources. In a typical DDoS attack, a large number of 
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compromised hosts are amassed to send useless packets. In recent years, the attack 
methods and tools have become more sophisticated, effective, and more difficult to 
trace to the real attackers, while defense technologies have been unable to with- 
stand large-scale attacks [CHANO2]. 

A denial of service (DoS) attack is an attempt to prevent legitimate users of a 
service from using that service. When this attack comes from a single host or net- 
work node, then it is simply referred to as a DoS attack. A more serious threat is 
posed by a DDoS attack. In a DDoS attack, an attacker is able to recruit a number 
of hosts throughout the Internet to simultaneously or in a coordinated fashion 
launch an attack upon the target. This section is concerned with DDoS attacks. First, 
we look at the nature and types of attacks. Next, we examine means by which an 
attacker is able to recruit a network of hosts for attack launch. Finally, this section 
looks at countermeasures. 


DDoS Attack Description 


A DDoS attack attempts to consume the target’s resources so that it cannot provide 
service. One way to classify DDoS attacks is in terms of the type of resource that is 
consumed. Broadly speaking, the resource consumed is either an internal host 
resource on the target system or data transmission capacity in the local network to 
which the target is attacked. 

A simple example of an internal resource attack is the SYN flood attack. 
Figure 21.9a shows the steps involved: 


1. The attacker takes control of multiple hosts over the Internet, instructing 
them to contact the target Web server. 


nN 


. The slave hosts begin sending TCP/IP SYN (synchronize/initialization) packets, 
with erroneous return IP address information, to the target. 


3. Each SYN packet is a request to open a TCP connection. For each such 
packet, the Web server responds with a SYN/ACK (synchronize/acknowl- 
edge) packet, trying to establish a TCP connection with a TCP entity at a spu- 
rious IP address. The Web server maintains a data structure for each SYN 
request waiting for a response back and becomes bogged down as more traffic 
floods in. The result is that legitimate connections are denied while the victim 
machine is waiting to complete bogus “half-open” connections. 


The TCP state data structure is a popular internal resource target but by no 
means the only one. [CERT01] gives the following examples: 


1. In many systems, a limited number of data structures are available to hold 
process information (process identifiers, process table entries, process slots, etc.). 
An intruder may be able to consume these data structures by writing a simple 
program or script that does nothing but repeatedly create copies of itself. 


2. An intruder may also attempt to consume disk space in other ways, including 
° generating excessive numbers of mail messages 
e intentionally generating errors that must be logged 


e placing files in anonymous ftp areas or network-shared areas 
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Figure 21.9 Examples of Simple DDoS Attacks 
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Figure 21.9b illustrates an example of an attack that consumes data transmis- 
sion resources. The following steps are involved: 


1. The attacker takes control of multiple hosts over the Internet, instructing 
them to send ICMP ECHO packets’ with the target’s spoofed IP address to a 
group of hosts that act as reflectors, as described subsequently. 


nN 


. Nodes at the bounce site receive multiple spoofed requests and respond by send- 
ing echo reply packets to the target site. 


= 


The target’s router is flooded with packets from the bounce site, leaving no 
data transmission capacity for legitimate traffic. 


Another way to classify DDoS attacks is as either direct or reflector DDoS 
attacks. In a direct DDoS attack (Figure 21.10a), the attacker is able to implant zom- 
bie software on a number of sites distributed throughout the Internet. Often, the 
DDoS attack involves two levels of zombie machines: master zombies and slave zom- 
bies. The hosts of both machines have been infected with malicious code. The attacker 
coordinates and triggers the master zombies, which in turn coordinate and trigger 
the slave zombies. The use of two levels of zombies makes it more difficult to trace the 
attack back to its source and provides for a more resilient network of attackers. 

A reflector DDoS attack adds another layer of machines (Figure 21.10b). In 
this type of attack, the slave zombies construct packets requiring a response that 
contains the target’s IP address as the source IP address in the packet’s IP header. 
These packets are sent to uninfected machines known as reflectors. The uninfected 
machines respond with packets directed at the target machine. A reflector DDoS 
attack can easily involve more machines and more traffic than a direct DDoS attack 
and hence be more damaging. Further, tracing back the attack or filtering out the 
attack packets is more difficult because the attack comes from widely dispersed 
uninfected machines. 


Constructing the Attack Network 


The first step in a DDoS attack is for the attacker to infect a number of machines 
with zombie software that will ultimately be used to carry out the attack. The essen- 
tial ingredients in this phase of the attack are the following: 


1. Software that can carry out the DDoS attack. The software must be able to run 
on a large number of machines, must be able to conceal its existence, must be 
able to communicate with the attacker or have some sort of time-triggered 
mechanism, and must be able to launch the intended attack toward the target. 


n 


A vulnerability in a large number of systems. The attacker must become aware of 
a vulnerability that many system administrators and individual users have failed 
to patch and that enables the attacker to install the zombie software. 


3. A strategy for locating vulnerable machines, a process known as scanning. 


3The Internet Control Message Protocol (ICMP) is an IP-level protocol for the exchange of control pack- 
ets between a router and a host or between hosts. The ECHO packet requires the recipient to respond 
with an echo reply to check that communication is possible between entities. 
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Figure 21.10 Types of Flooding-Based DDoS Attacks 


In the scanning process, the attacker first seeks out a number of vulnerable 
machines and infects them. Then, typically, the zombie software that is installed in 
the infected machines repeats the same scanning process, until a large distributed 
network of infected machines is created. [MIRK04] lists the following types of scan- 
ning strategies: 


e Random: Each compromised host probes random addresses in the IP address 
space, using a different seed. This technique produces a high volume of 
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Internet traffic, which may cause generalized disruption even before the actual 
attack is launched. 


e Hit-List: The attacker first compiles a long list of potential vulnerable 
machines. This can be a slow process done over a long period to avoid detec- 
tion that an attack is underway. Once the list is compiled, the attacker begins 
infecting machines on the list. Each infected machine is provided with a 
portion of the list to scan. This strategy results in a very short scanning period, 
which may make it difficult to detect that infection is taking place. 


e Topological: This method uses information contained on an infected victim 
machine to find more hosts to scan. 


e Local subnet: If a host can be infected behind a firewall, that host then looks 
for targets in its own local network. The host uses the subnet address structure 
to find other hosts that would otherwise be protected by the firewall. 


DDoS Countermeasures 


In general, there are three lines of defense against DDoS attacks [CHANO2]: 


e Attack prevention and preemption (before the attack): These mechanisms 
enable the victim to endure attack attempts without denying service to legiti- 
mate clients. Techniques include enforcing policies for resource consumption 
and providing backup resources available on demand. In addition, prevention 
mechanisms modify systems and protocols on the Internet to reduce the possi- 
bility of DDoS attacks. 


e Attack detection and filtering (during the attack): These mechanisms attempt to 
detect the attack as it begins and respond immediately. This minimizes the impact 
of the attack on the target. Detection involves looking for suspicious patterns of 
behavior. Response involves filtering out packets likely to be part of the attack. 


e Attack source traceback and identification (during and after the attack): This 
is an attempt to identify the source of the attack as a first step in preventing 
future attacks. However, this method typically does not yield results fast 
enough, if at all, to mitigate an ongoing attack. 


The challenge in coping with DDoS attacks is the sheer number of ways in 
which they can operate. Thus DDoS countermeasures must evolve with the threat. 


21.6 RECOMMENDED READING AND WEB SITES 


For a thorough understanding of viruses, the book to read is [SZORO05]. Another excellent 
treatment is [AYCO06]. Good overview articles on viruses and worms are [CASSO1], 
[FORR97], [KEPH97a], and [NACH97]. [MEINO1] provides a good treatment of the Code 
Red worm. [WEAV03] is a comprehensive survey of worm characteristics. [HYPP06] dis- 
cusses worm attacks on mobile phones. 

[PATRO04] is a worthwhile survey of DDoS attacks. [MIRK04] is a thorough description 
of the variety of DDoS attacks and countermeasures. [CHANO2] is a good examination of 
DDoS defense strategies. 
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Recommended Web Sites: 


e AntiVirus Online: IBM’s site on virus information. 


e Vmyths: Dedicated to exposing virus hoaxes and dispelling misconceptions about real 
viruses. 


e VirusList: Site maintained by commercial antivirus software provider. Good collection 
of useful information. 


e DDoS Attacks/Tools: Extensive list of links and documents. 


21.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


backdoor 
behavior- 


blended attack 


boot-sector virus 


macro virus 
malicious software 
malware 
metamorphic virus 


distributed denial of service 
(DDoS) 

downloaders 

e-mail virus 


blocking software 


digital immune system 
direct DDoS attack 


flooder 
logic bomb 


mobile code 
parasitic virus 
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polymorphic virus stealth virus virus 


reflector DDoS attack trapdoor worm 
scanning Trojan horse zero-day exploit 


Review Questions 


21.1 What is the role of compression in the operation of a virus? 
21.2. What is the role of encryption in the operation of a virus? 
21.3. What are typical phases of operation of a virus or worm? 
21.4 What is a digital immune system? 

21.5 How does behavior-blocking software work? 

21.6 In general terms, how does a worm propagate? 

21.7 Describe some worm countermeasures. 

21.8 What isa DDoS? 


Problems 


21.1 There is a flaw in the virus program of Figure 21.1. What is it? 


21.2 The question arises as to whether it is possible to develop a program that can analyze 
a piece of software to determine if it is a virus. Consider that we have a program D 
that is supposed to be able to do that. That is, for any program P, if we run D(P), the 
result returned is TRUE (P is a virus) or FALSE (P is not a virus). Now consider the 
following program: 


Program CV := 
{ 
main-program := 
{if D(CV) then goto next: 
else infect-executable; 
} 
next: 
} 
In the preceding program, infect-executable is a module that scans memory for exe- 
cutable programs and replicates itself in those programs. Determine if D can correctly 
decide whether CV is a virus. 


The point of this problem is to demonstrate the type of puzzles that must be solved in 
the design of malicious code and therefore, the type of mindset that one wishing to 
counter such attacks must adopt. 

a. Consider the following C program: 


nN 
—_ 
as) 


begin 
print (*begin print (); end.*); 
end 
What do you think the program was intended to do? Does it work? 
b. Answer the same questions for the following program: 


char {] = £20; 1 We a bats hm Nats Wa th Pant ¢ 
Nets P)tae BLY, anid SO (Otiee. “Ey 9)", SO" pe 
main () 
{ 
Tne is 


printf£(*char t[] = (*); 
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for (i=0; t[i]!=0; i=i+1) 
printf("sd, ", til); 
printf("%s", t); 
} 


c. What is the specific relevance of this problem to this chapter? 
21.4 Consider the following fragment: 
legitimate code 
if data is Friday the 13th; 
crash_computer () ; 
legitimate code 


What type of malicious software is this? 
Consider the following fragment in an authentication program: 


i) 
_ 
mn 


username = read_username() ; 

password = read_password(); 

if username is "133t h4ck0r" 
return ALLOW_LOGIN; 

if username and password are valid 
return ALLOW_LOGIN 

else return DENY_LOGIN 

What type of malicious software is this? 


21.6 The following code fragments show a sequence of virus instructions and a metamor- 
phic version of the virus. Describe the effect produced by the metamorphic code. 


Original Code Metamorphic Code 

mov eax, 5 mov eax, 5 

add eax, ebx push ecx 

call [eax] pop ecx 
add eax, ebx 
swap eax, ebx 
swap ebx, eax 
call [eax] 
nop 


21.7 The list of passwords used by the Morris worm is provided at this book’s Web site. 
a. The assumption has been expressed by many people that this list represents words 
commonly used as passwords. Does this seem likely? Justify your answer. 
b. If the list does not reflect commonly used passwords, suggest some approaches 
that Morris may have used to construct the list. 


21.8 Suggest some methods of attacking the PWC worm defense that could be used by 
worm creators and suggest countermeasures to these methods. 
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The function of a strong position is to make the forces holding it practically 
unassailable. 
—On War, Carl Von Clausewitz 


On the day that you take up your command, block the frontier passes, destroy the 
official tallies, and stop the passage of all emissaries. 


—The Art of War, Sun Tzu 


KEY POINTS 


® A firewall forms a barrier through which the traffic going in each direction 
must pass. A firewall security policy dictates which traffic is authorized to 
pass in each direction. 


® A firewall may be designed to operate as a filter at the level of IP packets, 
or may operate at a higher protocol layer. 


Firewalls can be an effective means of protecting a local system or network of systems 
from network-based security threats while at the same time affording access to the out- 
side world via wide area networks and the Internet. 


22.1 THE NEED FOR FIREWALLS 


Information systems in corporations, government agencies, and other organizations 
have undergone a steady evolution. The following are notable developments: 


e Centralized data processing system, with a central mainframe supporting a 
number of directly connected terminals 


e Local area networks (LANs) interconnecting PCs and terminals to each other 
and the mainframe 


e Premises network, consisting of a number of LANs, interconnecting PCs, 
servers, and perhaps a mainframe or two 


e Enterprise-wide network, consisting of multiple, geographically distributed 
premises networks interconnected by a private wide area network (WAN) 


e Internet connectivity, in which the various premises networks all hook into the 
Internet and may or may not also be connected by a private WAN 


Internet connectivity is no longer optional for organizations. The information 
and services available are essential to the organization. Moreover, individual users 
within the organization want and need Internet access, and if this is not provided via 
their LAN, they will use dial-up capability from their PC to an Internet service 
provider (ISP). However, while Internet access provides benefits to the organization, 
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it enables the outside world to reach and interact with local network assets. This 
creates a threat to the organization. While it is possible to equip each workstation 
and server on the premises network with strong security features, such as intrusion 
protection, this may not be sufficient and in some cases is not cost-effective. Consider 
a network with hundreds or even thousands of systems, running various operating 
systems, such as different versions of UNIX and Windows. When a security flaw is 
discovered, each potentially affected system must be upgraded to fix that flaw. This 
requires scaleable configuration management and aggressive patching to function 
effectively. While difficult, this is possible and is necessary if only host-based security 
is used. A widely accepted alternative or at least complement to host-based security 
services is the firewall. The firewall is inserted between the premises network and the 
Internet to establish a controlled link and to erect an outer security wall or perime- 
ter. The aim of this perimeter is to protect the premises network from Internet-based 
attacks and to provide a single choke point where security and auditing can be 
imposed. The firewall may be a single computer system or a set of two or more 
systems that cooperate to perform the firewall function. 

The firewall, then, provides an additional layer of defense, insulating the inter- 
nal systems from external networks. This follows the classic military doctrine of 
“defense in depth,” which is just as applicable to IT security. 


22.2 FIREWALL CHARACTERISTICS 


[BELL94b] lists the following design goals for a firewall: 


1. All traffic from inside to outside, and vice versa, must pass through the firewall. 
This is achieved by physically blocking all access to the local network except 
via the firewall. Various configurations are possible, as explained later in this 
chapter. 


n 


Only authorized traffic, as defined by the local security policy, will be allowed to 
pass. Various types of firewalls are used, which implement various types of secu- 
rity policies, as explained later in this chapter. 


3. The firewall itself is immune to penetration. This implies the use of a hardened 
system with a secured operating system. Trusted computer systems are suitable 
for hosting a firewall and often required in government applications. 


[SMIT97] lists four general techniques that firewalls use to control access and 
enforce the site’s security policy. Originally, firewalls focused primarily on service 
control, but they have since evolved to provide all four: 


e Service control: Determines the types of Internet services that can be 
accessed, inbound or outbound. The firewall may filter traffic on the basis of 
IP address, protocol, or port number; may provide proxy software that receives 
and interprets each service request before passing it on; or may host the server 
software itself, such as a Web or mail service. 


e Direction control: Determines the direction in which particular service 
requests may be initiated and allowed to flow through the firewall. 
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e User control: Controls access to a service according to which user is attempt- 
ing to access it. This feature is typically applied to users inside the firewall 
perimeter (local users). It may also be applied to incoming traffic from exter- 
nal users; the latter requires some form of secure authentication technology, 
such as is provided in IPsec (Chapter 19). 


e Behavior control: Controls how particular services are used. For example, the 
firewall may filter e-mail to eliminate spam, or it may enable external access to 
only a portion of the information on a local Web server. 


Before proceeding to the details of firewall types and configurations, it is best 


to summarize what one can expect from a firewall. The following capabilities are 
within the scope of a firewall: 


1. A firewall defines a single choke point that keeps unauthorized users out of 


the protected network, prohibits potentially vulnerable services from entering 
or leaving the network, and provides protection from various kinds of IP 
spoofing and routing attacks. The use of a single choke point simplifies security 
management because security capabilities are consolidated on a single system 
or set of systems. 


. A firewall provides a location for monitoring security-related events. Audits and 
alarms can be implemented on the firewall system. 


3. A firewall is a convenient platform for several Internet functions that are not 


security related. These include a network address translator, which maps local 
addresses to Internet addresses, and a network management function that audits 
or logs Internet usage. 


4. A firewall can serve as the platform for IPsec. Using the tunnel mode capabil- 


ity described in Chapter 19, the firewall can be used to implement virtual 
private networks. 


Firewalls have their limitations, including the following: 


1. The firewall cannot protect against attacks that bypass the firewall. Internal 


systems may have dial-out capability to connect to an ISP. An internal LAN 
may support a modem pool that provides dial-in capability for traveling 
employees and telecommuters. 


. The firewall may not protect fully against internal threats, such as a disgruntled 
employee or an employee who unwittingly cooperates with an external 
attacker. 


3. Animproperly secured wireless LAN may be accessed from outside the organi- 


zation. An internal firewall that separates portions of an enterprise network 
cannot guard against wireless communications between local systems on differ- 
ent sides of the internal firewall. 


4. A laptop, PDA, or portable storage device may be used and infected outside 


the corporate network, and then attached and used internally. 
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22.3 TYPES OF FIREWALLS 


A firewall may act as a packet filter. It can operate as a positive filter, allowing to 
pass only packets that meet specific criteria, or as a negative filter, rejecting any 
packet that meets certain criteria. Depending on the type of firewall, it may examine 
one or more protocol headers in each packet, the payload of each packet, or the pat- 
tern generated by a sequence of packets. In this section, we look at the principal 
types of firewalls. 


Packet Filtering Firewall 


A packet filtering firewall applies a set of rules to each incoming and outgoing IP 
packet and then forwards or discards the packet (Figure 22.1b). The firewall is typi- 
cally configured to filter packets going in both directions (from and to the internal 
network). Filtering rules are based on information contained in a network packet: 


e Source IP address: The IP address of the system that originated the IP packet 
(e.g., 192.178.1.1) 


e Destination IP address: The IP address of the system the IP packet is trying to 
reach (e.g., 192.168.1.2) 


Source and destination transport-level address: The transport-level (e.g., TCP 
or UDP) port number, which defines applications such as SNMP or TELNET 


IP protocol field: Defines the transport protocol 


e 


Interface: For a firewall with three or more ports, which interface of the fire- 
wall the packet came from or which interface of the firewall the packet is des- 
tined for 


The packet filter is typically set up as a list of rules based on matches to fields 
in the IP or TCP header. If there is a match to one of the rules, that rule is invoked 
to determine whether to forward or discard the packet. If there is no match to any 
rule, then a default action is taken. Two default policies are possible: 


e Default = discard: That which is not expressly permitted is prohibited. 
e Default = forward: That which is not expressly prohibited is permitted. 


The default discard policy is more conservative. Initially, everything is 
blocked, and services must be added on a case-by-case basis. This policy is more 
visible to users, who are more likely to see the firewall as a hindrance. However, 
this is the policy likely to be preferred by businesses and government organiza- 
tions. Further, visibility to users diminishes as rules are created. The default for- 
ward policy increases ease of use for end users but provides reduced security; the 
security administrator must, in essence, react to each new security threat as it 
becomes known. This policy may be used by generally more open organizations, 
such as universities. 

Table 22.1, from [BELL94b], gives some examples of packet filtering rulesets. 
In each set, the rules are applied top to bottom. The “*” in a field is a wildcard 


22-6 


Internal (protected) network 
(e.g., enterprise network) 


CHAPTER 22 / FIREWALLS 


External (untrusted) network 


Firewall (e.g., Internet) 
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(d) Application proxy firewall 


Figure 22.1 Types of Firewalls 
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Packet-Filtering Examples 


Rule Set A 


SPIGOT we don’t trust these people 
connection to our SMTP port 


Rule Set B 


action ourhost theirhost port comment 


block 2 : : default 


Rule Set C 


action ourhost theirhost port comment 


allow cy : connection to their SMTP port 


Rule Set D 


action src comment 


allow {our hosts} our packets to their SMTP port 


allow s their replies 


action src comment 


allow {our hosts} our outgoing calls 


allow is ; ; replies to our calls 


allow * K traffic to nonservers 


designator that matches everything. We assume that the default = discard policy is 
in force. 


A 


B. 


D. 


Inbound mail is allowed (port 25 is for SMTP incoming), but only to a gateway 
host. However, packets from a particular external host, SPIGOT, are blocked 
because that host has a history of sending massive files in e-mail messages. 


This is an explicit statement of the default policy. All rulesets include this rule 
implicitly as the last rule. 


’. This ruleset is intended to specify that any inside host can send mail to the out- 


side. A TCP packet with a destination port of 25 is routed to the SMTP server on 
the destination machine. The problem with this rule is that the use of port 25 for 
SMTP receipt is only a default; an outside machine could be configured to have 
some other application linked to port 25. As this rule is written, an attacker could 
gain access to internal machines by sending packets with a TCP source port num- 
ber of 25. 


This ruleset achieves the intended result that was not achieved in C. The rules 
take advantage of a feature of TCP connections. Once a connection is set up, the 
ACK flag of a TCP segment is set to acknowledge segments sent from the other 
side. Thus, this ruleset states that it allows IP packets where the source IP address 
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is one of a list of designated internal hosts and the destination TCP port number 
is 25. It also allows incoming packets with a source port number of 25 that include 
the ACK flag in the TCP segment. Note that we explicitly designate source and 
destination systems to define these rules explicitly. 


. This ruleset is one approach to handling FTP connections. With FTP, two TCP 


connections are used: a control connection to set up the file transfer and a data 
connection for the actual file transfer. The data connection uses a different port 
number that is dynamically assigned for the transfer. Most servers, and hence 
most attack targets, use low-numbered ports; most outgoing calls tend to use a 
higher-numbered port, typically above 1023. Thus, this ruleset allows 


— Packets that originate internally 
— Reply packets to a connection initiated by an internal machine 
— Packets destined for a high-numbered port on an internal machine 


This scheme requires that the systems be configured so that only the appropriate 
port numbers are in use. 


Rule set E points out the difficulty in dealing with applications at the packet- 


filtering level. Another way to deal with FTP and similar applications is either state- 
ful packet filters or an application-level gateway, both described subsequently in this 
section. 


One advantage of a packet filtering firewall is its simplicity. Also, packet filters 


typically are transparent to users and are very fast. [WACK02] lists the following 
weaknesses of packet filter firewalls: 


Because packet filter firewalls do not examine upper-layer data, they cannot 
prevent attacks that employ application-specific vulnerabilities or functions. 
For example, a packet filter firewall cannot block specific application 
commands; if a packet filter firewall allows a given application, all functions 
available within that application will be permitted. 


Because of the limited information available to the firewall, the logging func- 
tionality present in packet filter firewalls is limited. Packet filter logs normally 
contain the same information used to make access control decisions (source 
address, destination address, and traffic type). 


Most packet filter firewalls do not support advanced user authentication 
schemes. Once again, this limitation is mostly due to the lack of upper-layer 
functionality by the firewall. 


Packet filter firewalls are generally vulnerable to attacks and exploits that 
take advantage of problems within the TCP/IP specification and protocol 
stack, such as network layer address spoofing. Many packet filter firewalls 
cannot detect a network packet in which the OSI Layer 3 addressing informa- 
tion has been altered. Spoofing attacks are generally employed by intruders to 
bypass the security controls implemented in a firewall platform. 

Finally, due to the small number of variables used in access control decisions, 
packet filter firewalls are susceptible to security breaches caused by improper 
configurations. In other words, it is easy to accidentally configure a packet 
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filter firewall to allow traffic types, sources, and destinations that should be 
denied based on an organization’s information security policy. 


Some of the attacks that can be made on packet filtering firewalls and the 
appropriate countermeasures are the following: 


e IP address spoofing: The intruder transmits packets from the outside with a 
source IP address field containing an address of an internal host. The attacker 
hopes that the use of a spoofed address will allow penetration of systems that 
employ simple source address security, in which packets from specific trusted 
internal hosts are accepted. The countermeasure is to discard packets with an 
inside source address if the packet arrives on an external interface. In fact, this 
countermeasure is often implemented at the router external to the firewall. 


e Source routing attacks: The source station specifies the route that a packet 
should take as it crosses the Internet, in the hopes that this will bypass security 
measures that do not analyze the source routing information. The counter- 
measure is to discard all packets that use this option. 


e Tiny fragment attacks: The intruder uses the IP fragmentation option to create 
extremely small fragments and force the TCP header information into a sepa- 
rate packet fragment. This attack is designed to circumvent filtering rules that 
depend on TCP header information. Typically, a packet filter will make a fil- 
tering decision on the first fragment of a packet. All subsequent fragments of 
that packet are filtered out solely on the basis that they are part of the packet 
whose first fragment was rejected. The attacker hopes that the filtering firewall 
examines only the first fragment and that the remaining fragments are passed 
through. A tiny fragment attack can be defeated by enforcing a rule that the 
first fragment of a packet must contain a predefined minimum amount of 
the transport header. If the first fragment is rejected, the filter can remember 
the packet and discard all subsequent fragments. 


Stateful Inspection Firewalls 


A traditional packet filter makes filtering decisions on an individual packet basis 
and does not take into consideration any higher layer context. To understand what is 
meant by context and why a traditional packet filter is limited with regard to con- 
text, a little background is needed. Most standardized applications that run on top of 
TCP follow a client/server model. For example, for the Simple Mail Transfer 
Protocol (SMTP), e-mail is transmitted from a client system to a server system. The 
client system generates new e-mail messages, typically from user input. The server 
system accepts incoming e-mail messages and places them in the appropriate user 
mailboxes. SMTP operates by setting up a TCP connection between client and 
server, in which the TCP server port number, which identifies the SMTP server 
application, is 25. The TCP port number for the SMTP client is a number between 
1024 and 65535 that is generated by the SMTP client. 

In general, when an application that uses TCP creates a session with a remote 
host, it creates a TCP connection in which the TCP port number for the remote 
(server) application is a number less than 1024 and the TCP port number for the local 
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(client) application is a number between 1024 and 65535. The numbers less than 1024 
are the “well-known” port numbers and are assigned permanently to particular 
applications (e.g., 25 for server SMTP). The numbers between 1024 and 65535 are 
generated dynamically and have temporary significance only for the lifetime of a 
TCP connection. 

A simple packet filtering firewall must permit inbound network traffic on all 
these high-numbered ports for TCP-based traffic to occur. This creates a vulnerabil- 
ity that can be exploited by unauthorized users. 

A stateful inspection packet firewall tightens up the rules for TCP traffic by 
creating a directory of outbound TCP connections, as shown in Table 22.2. There is 
an entry for each currently established connection. The packet filter will now allow 
incoming traffic to high-numbered ports only for those packets that fit the profile of 
one of the entries in this directory. 

A stateful packet inspection firewall reviews the same packet information as a 
packet filtering firewall, but also records information about TCP connections 
(Figure 22.1c). Some stateful firewalls also keep track of TCP sequence numbers to 
prevent attacks that depend on the sequence number, such as session hijacking. Some 
even inspect limited amounts of application data for some well-known protocols like 
FTP, IM and SIPS commands, in order to identify and track related connections. 


Application-Level Gateway 


An application-level gateway, also called an application proxy, acts as a relay of 
application-level traffic (Figure 22.1d). The user contacts the gateway using a 
TCP/IP application, such as Telnet or FTP, and the gateway asks the user for the 
name of the remote host to be accessed. When the user responds and provides a 
valid user ID and authentication information, the gateway contacts the application 
on the remote host and relays TCP segments containing the application data 
between the two endpoints. If the gateway does not implement the proxy code for a 
specific application, the service is not supported and cannot be forwarded across the 
firewall. Further, the gateway can be configured to support only specific features of 


Table 22.2 Example Stateful Firewall Connection State Table [WACK02] 


Source Address | Source Port Destination Destination Port Connection 
Address State 


192.168.1.100 210.22.88.29 Established 


192.168.1.102 216.32.42.123 Established 
192.168.1.101 W/StGG 322122 Established 


192.168.1.106 ie 2o les 2a Established 
223.43.21.231 192.168.1.6 Established 


NODA 32) 192.168.1.6 Established 


210.922.212.18 192.168.1.6 Established 
24.102.32.23 192.168.1.6 Established 


BEIM OMY 192.168.1.6 Established 
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an application that the network administrator considers acceptable while denying 
all other features. 

Application-level gateways tend to be more secure than packet filters. Rather 
than trying to deal with the numerous possible combinations that are to be allowed 
and forbidden at the TCP and IP level, the application-level gateway need only 
scrutinize a few allowable applications. In addition, it is easy to log and audit all 
incoming traffic at the application level. 

A prime disadvantage of this type of gateway is the additional processing 
overhead on each connection. In effect, there are two spliced connections between 
the end users, with the gateway at the splice point, and the gateway must examine 
and forward all traffic in both directions. 


Circuit-Level Gateway 


A fourth type of firewall is the circuit-level gateway or circuit-level proxy 
(Figure 22.1e). This can be a stand-alone system or it can be a specialized func- 
tion performed by an application-level gateway for certain applications. As with 
an application gateway, a circuit-level gateway does not permit an end-to-end 
TCP connection; rather, the gateway sets up two TCP connections, one between 
itself and a TCP user on an inner host and one between itself and a TCP user on 
an outside host. Once the two connections are established, the gateway typically 
relays TCP segments from one connection to the other without examining the 
contents. The security function consists of determining which connections will be 
allowed. 

A typical use of circuit-level gateways is a situation in which the system admin- 
istrator trusts the internal users. The gateway can be configured to support applica- 
tion-level or proxy service on inbound connections and circuit-level functions for 
outbound connections. In this configuration, the gateway can incur the processing 
overhead of examining incoming application data for forbidden functions but does 
not incur that overhead on outgoing data. 

An example of a circuit-level gateway implementation is the SOCKS package 
[KOBL92]; version 5 of SOCKS is specified in RFC 1928. The RFC defines SOCKS 
in the following fashion: 


The protocol described here is designed to provide a framework for 
client-server applications in both the TCP and UDP domains to 
conveniently and securely use the services of a network firewall. 
The protocol is conceptually a “shim-layer” between the application 
layer and the transport layer, and as such does not provide network- 
layer gateway services, such as forwarding of ICMP messages. 


SOCKS consists of the following components: 


e The SOCKS server, which often runs on a UNIX-based firewall. SOCKS is 
also implemented on Windows systems. 


e The SOCKS client library, which runs on internal hosts protected by the 
firewall. 
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e SOCKS-ified versions of several standard client programs such as FTP and 
TELNET. The implementation of the SOCKS protocol typically involves 
either the recompilation or relinking of TCP-based client applications, or the 
use of alternate dynamically loaded libraries, to use the appropriate encapsu- 
lation routines in the SOCKS library. 


When a TCP-based client wishes to establish a connection to an object that is 
reachable only via a firewall (such determination is left up to the implementa- 
tion), it must open a TCP connection to the appropriate SOCKS port on the 
SOCKS server system. The SOCKS service is located on TCP port 1080. If the con- 
nection request succeeds, the client enters a negotiation for the authentication 
method to be used, authenticates with the chosen method, and then sends a relay 
request. The SOCKS server evaluates the request and either establishes the 
appropriate connection or denies it. UDP exchanges are handled in a similar fash- 
ion. In essence, a TCP connection is opened to authenticate a user to send and 
receive UDP segments, and the UDP segments are forwarded as long as the TCP 
connection is open. 


22.4 FIREWALL BASING 


It is common to base a firewall on a stand-alone machine running a common oper- 
ating system, such as UNIX or Linux. Firewall functionality can also be imple- 
mented as a software module in a router or LAN switch. In this section, we look at 
some additional firewall basing considerations. 


Bastion Host 


A bastion host is a system identified by the firewall administrator as a critical strong 
point in the network’s security. Typically, the bastion host serves as a platform for an 
application-level or circuit-level gateway. Common characteristics of a bastion host 
are as follows: 


e The bastion host hardware platform executes a secure version of its operating 
system, making it a hardened system. 


e Only the services that the network administrator considers essential are 
installed on the bastion host. These could include proxy applications for DNS, 
FTP, HTTP, and SMTP. 


e The bastion host may require additional authentication before a user is 
allowed access to the proxy services. In addition, each proxy service may 
require its own authentication before granting user access. 

e Each proxy is configured to support only a subset of the standard application’s 
command set. 

e Each proxy is configured to allow access only to specific host systems. This 
means that the limited command/feature set may be applied only to a subset of 
systems on the protected network. 
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e Each proxy maintains detailed audit information by logging all traffic, each 
connection, and the duration of each connection. The audit log is an essential 
tool for discovering and terminating intruder attacks. 


e Each proxy module is a very small software package specifically designed for 
network security. Because of its relative simplicity, it is easier to check such 
modules for security flaws. For example, a typical UNIX mail application may 
contain over 20,000 lines of code, while a mail proxy may contain fewer 
than 1000. 


e Each proxy is independent of other proxies on the bastion host. If there is a 
problem with the operation of any proxy, or if a future vulnerability is discov- 
ered, it can be uninstalled without affecting the operation of the other proxy 
applications. Also, if the user population requires support for a new service, 
the network administrator can easily install the required proxy on the 
bastion host. 


e A proxy generally performs no disk access other than to read its initial config- 
uration file. Hence, the portions of the file system containing executable code 
can be made read only. This makes it difficult for an intruder to install Trojan 
horse sniffers or other dangerous files on the bastion host. 


e Each proxy runs as a nonprivileged user in a private and secured directory on 
the bastion host. 


Host-Based Firewalls 


A host-based firewall is a software module used to secure an individual host. 
Such modules are available in many operating systems or can be provided as an 
add-on package. Like conventional stand-alone firewalls, host-resident firewalls 
filter and restrict the flow of packets. A common location for such firewalls is a 
server. There are several advantages to the use of a server-based or workstation- 
based firewall: 


e Filtering rules can be tailored to the host environment. Specific corporate 
security policies for servers can be implemented, with different filters for 
servers used for different application. 


e Protection is provided independent of topology. Thus both internal and exter- 
nal attacks must pass through the firewall. 


e Used in conjunction with stand-alone firewalls, the host-based firewall pro- 
vides an additional layer of protection. A new type of server can be added to 
the network, with its own firewall, without the necessity of altering the net- 
work firewall configuration. 


Personal Firewall 


A personal firewall controls the traffic between a personal computer or workstation 
on one side and the Internet or enterprise network on the other side. Personal fire- 
wall functionality can be used in the home environment and on corporate intranets. 
Typically, the personal firewall is a software module on the personal computer. In a 
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home environment with multiple computers connected to the Internet, firewall 
functionality can also be housed in a router that connects all of the home computers 
to a DSL, cable modem, or other Internet interface. 

Personal firewalls are typically much less complex than either server-based 
firewalls or stand-alone firewalls. The primary role of the personal firewall is to deny 
unauthorized remote access to the computer. The firewall can also monitor outgoing 
activity in an attempt to detect and block worms and other malware. 

An example of a personal firewall is the capability built in to the Mac OS X 
operating system. When the user enables the personal firewall in Mac OS X, 
all inbound connections are denied except for those the user explicitly permits. 
Figure 22.2 shows this simple interface. The list of inbound services that can be 
selectively reenabled, with their port numbers, includes the following: 


e Personal file sharing (548, 427) 

e Windows sharing (139) 

e Personal Web sharing (80, 427) 

e Remote login - SSH (22) 

e FTP access (20-21, 1024-64535 from 20-21) 
e Remote Apple events (3031) 

e Printer sharing (631, 515) 

e IChat Rendezvous (5297, 5298) 

e ITunes Music Sharing (3869) 

e CVS (2401) 


Services Firewall Internet 


Firewall On 


( ~ Stop _ ) Click Stop to allow incoming network communication to all services and 

ce a 

Allow: On _ Description (Ports) 

Personal File Sharing (548, 427) = 

Windows Sharing (139) * ( New... ) 
Personal Web Sharing (80. 427) 
Remote Login - SSH (22) 

FTP Access (20-21, 1024-65535 from 20-21) C Delete) 
Remote Apple Events (3031) === 
Printer Sharing (631, 515) 


( Edit...) 


To use FTP to retrieve files while the firewall is on, enable passive FTP mode using the Proxies 
tab in Network Preferences. ( 


( ou) 


Figure 22.2 Example Personal Firewall Interface 
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Gnutella/Limewire (6346) 
ICQ (4000) 

e IRC (194) 

e MSN Messenger (6891-6900) 

e Network Time (123) 

e Retrospect (497) 

e SMB (without netbios-445) 
Timbuktu (407) 

VNC (5900-5902) 

e WebSTAR Admin (1080, 1443) 


When FTP access is enabled, ports 20 and 21 on the local machine are opened 
for FTP; if others connect to this computer from ports 20 or 21, the ports 1024 
through 64535 are open. 

For increased protection, advanced firewall features are available through 
easy-to-configure checkboxes. Stealth mode hides the Mac on the Internet by drop- 
ping unsolicited communication packets, making it appear as though no Mac is 
present. UDP packets can be blocked, restricting network traffic to TCP packets 
only for open ports. The firewall also supports logging, an important tool for check- 
ing on unwanted activity. 


22.5 FIREWALL LOCATION AND CONFIGURATIONS 


As Figure 22.1a indicates, a firewall is positioned to provide a protective barrier 
between an external, potentially untrusted source of traffic and an internal network. 
With that general principle in mind, a security administrator must decide on the 
location and on the number of firewalls needed. In this section, we look at some 
common options. 


DMZ Networks 


Figure 22.3 suggests the most common distinction, that between an internal and an 
external firewall. An external firewall is placed at the edge of a local or enterprise 
network, just inside the boundary router that connects to the Internet or some wide 
area network (WAN). One or more internal firewalls protect the bulk of the enter- 
prise network. Between these two types of firewalls are one or more networked 
devices in a region referred to as a DMZ (demilitarized zone) network. Systems 
that are externally accessible but need some protections are usually located on 
DMZ networks. Typically, the systems in the DMZ require or foster external con- 
nectivity, such as a corporate Web site, an e-mail server, or a DNS (domain name 
system) server. 

The external firewall provides a measure of access control and protection for 
the DMZ systems consistent with their need for external connectivity. The external 
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Figure 22.3 Example Firewall Configuration 


firewall also provides a basic level of protection for the remainder of the enterprise 
network. In this type of configuration, internal firewalls serve three purposes: 


1. The internal firewall adds more stringent filtering capability, compared to the 
external firewall, in order to protect enterprise servers and workstations from 
external attack. 


2. The internal firewall provides two-way protection with respect to the DMZ. First, 
the internal firewall protects the remainder of the network from attacks launched 
from DMZ systems. Such attacks might originate from worms, rootkits, bots, or 
other malware lodged in a DMZ system. Second, an internal firewall can protect 
the DMZ systems from attack from the internal protected network. 
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3. Multiple internal firewalls can be used to protect portions of the internal 
network from each other. For example, firewalls can be configured so that 
internal servers are protected from internal workstations and vice versa. 
A common practice is to place the DMZ on a different network interface on 
the external firewall from that used to access the internal networks. 


Virtual Private Networks 


In today’s distributed computing environment, the virtual private network (VPN) 
offers an attractive solution to network managers. In essence, a VPN consists of a set 
of computers that interconnect by means of a relatively unsecure network and that 
make use of encryption and special protocols to provide security. At each corporate 
site, workstations, servers, and databases are linked by one or more local area net- 
works (LANs). The Internet or some other public network can be used to intercon- 
nect sites, providing a cost savings over the use of a private network and offloading 
the wide area network management task to the public network provider. That same 
public network provides an access path for telecommuters and other mobile 
employees to log on to corporate systems from remote sites. 

But the manager faces a fundamental requirement: security. Use of a public 
network exposes corporate traffic to eavesdropping and provides an entry point for 
unauthorized users. To counter this problem, a VPN is needed. In essence, a VPN 
uses encryption and authentication in the lower protocol layers to provide a secure 
connection through an otherwise insecure network, typically the Internet. VPNs are 
generally cheaper than real private networks using private lines but rely on having 
the same encryption and authentication system at both ends. The encryption may be 
performed by firewall software or possibly by routers. The most common protocol 
mechanism used for this purpose is at the IP level and is known as IPsec. 

An organization maintains LANs at dispersed locations. A logical means of 
implementing an IPsec is in a firewall, as shown in Figure 22.4, which essentially 
repeats Figure 19.1. If IPsec is implemented in a separate box behind (internal to) 
the firewall, then VPN traffic passing through the firewall in both directions is 
encrypted. In this case, the firewall is unable to perform its filtering function or 
other security functions, such as access control, logging, or scanning for viruses. 
IPsec could be implemented in the boundary router, outside the firewall. However, 
this device is likely to be less secure than the firewall and thus less desirable as an 
IPsec platform. 


Distributed Firewalls 


A distributed firewall configuration involves stand-alone firewall devices plus host- 
based firewalls working together under a central administrative control. Figure 22.5 
suggests a distributed firewall configuration. Administrators can configure host- 
resident firewalls on hundreds of servers and workstations as well as configure 
personal firewalls on local and remote user systems. Tools let the network adminis- 
trator set policies and monitor security across the entire network. These firewalls 
protect against internal attacks and provide protection tailored to specific machines 
and applications. Stand-alone firewalls provide global protection, including internal 
firewalls and an external firewall, as discussed previously. 
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Figure 22.4 A VPN Security Scenario 


With distributed firewalls, it may make sense to establish both an internal and 
an external DMZ. Web servers that need less protection because they have less 
critical information on them could be placed in an external DMZ, outside the exter- 
nal firewall. What protection is needed is provided by host-based firewalls on these 
servers. 

An important aspect of a distributed firewall configuration is security moni- 
toring. Such monitoring typically includes log aggregation and analysis, firewall 
statistics, and fine-grained remote monitoring of individual hosts if needed. 


Summary of Firewall Locations and Topologies 


We can now summarize the discussion from Sections 22.4 and 22.5 to define a 
spectrum of firewall locations and topologies. The following alternatives can be 
identified: 


¢ Host-resident firewall: This category includes personal firewall software and 
firewall software on servers. Such firewalls can be used alone or as part of an 
in-depth firewall deployment. 

e Screening router: A single router between internal and external networks with 
stateless or full packet filtering. This arrangement is typical for small 
office/home office (SOHO) applications. 
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e Single bastion inline: A single firewall device between an internal and external 
router (e.g., Figure 22.1a). The firewall may implement stateful filters and/or 
application proxies. This is the typical firewall appliance configuration for 
small to medium-sized organizations. 
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e Single bastion T: Similar to single bastion inline but has a third network 
interface on bastion to a DMZ where externally visible servers are placed. 
Again, this is a common appliance configuration for medium to large 
organizations. 


e Double bastion inline: Figure 22.3 illustrates this configuration, where the 
DMZ is sandwiched between bastion firewalls. This configuration is common 
for large businesses and government organizations. 


e Double bastion T: The DMZ is on a separate network interface on the bastion 
firewall. This configuration is also common for large businesses and govern- 
ment organizations and may be required. For example, this configuration is 
required for Australian government use (Australian Government Information 
Technology Security Manual - ACSI33). 


e Distributed firewall configuration: Illustrated in Figure 22.5. This configura- 
tion is used by some large businesses and government organizations. 
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22.7 KEY TERMS, REVIEW QUESTIONS, AND PROBLEMS 


Key Terms 


application-level gateway firewall personal firewall 
bastion host host-based firewall proxy 


circuit-level gateway IP address spoofing stateful inspection firewall 
distributed firewalls IP security (IPsec) tiny fragment attack 
DMZ packet filtering firewall virtual private network (VPN) 


Review Questions 


List three design goals for a firewall. 

List four techniques used by firewalls to control access and enforce a security policy. 
What information is used by a typical packet filtering firewall? 

What are some weaknesses of a packet filtering firewall? 


What is the difference between a packet filtering firewall and a stateful inspection 
firewall? 
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22.6 What is an application-level gateway? 
22.7 What is a circuit-level gateway? 
22.8 What are the differences among the firewalls of Figure 22.1? 
22.9 What are the common characteristics of a bastion host? 
22.10 Why is it useful to have host-based firewalls? 
22.11 What isa DMZ network and what types of systems would you expect to find on such 
networks? 
22.12 What is the difference between an internal and an external firewall? 
Problems 


22.1 As was mentioned in Section 22.3, one approach to defeating the tiny fragment attack 
is to enforce a minimum length of the transport header that must be contained in the 
first fragment of an IP packet. If the first fragment is rejected, all subsequent frag- 
ments can be rejected. However, the nature of IP is such that fragments may arrive 
out of order. Thus, an intermediate fragment may pass through the filter before the 
initial fragment is rejected. How can this situation be handled? 

In an IPv4 packet, the size of the payload in the first fragment, in octets, is equal to 
Total Length — (4 x IHL). If this value is less than the required minimum (8 octets for 
TCP), then this fragment and the entire packet are rejected. Suggest an alternative 
method of achieving the same result using only the Fragment Offset field. 

RFC 791, the IPv4 protocol specification, describes a reassembly algorithm that 
results in new fragments overwriting any overlapped portions of previously received 
fragments. Given such a reassembly implementation, an attacker could construct a 
series of packets in which the lowest (zero-offset) fragment would contain innocuous 
data (and thereby be passed by administrative packet filters), and in which some sub- 
sequent packet having a non-zero offset would overlap TCP header information (des- 
tination port, for instance) and cause it to be modified. The second packet would be 
passed through most filter implementations because it does not have a zero fragment 
offset. Suggest a method that could be used by a packet filter to counter this attack. 
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Table 22.3 Sample Packet Filter Firewall Ruleset 


Source Address Source Port Dest Address Dest Port Action 


Any 192.168.1.0 > 1023 Allow 


192.168.1.1 Any 


192.168.1.1 


Deny 


Any 


Deny 
192.168.1.0 


Ip) Alopeh I 
192.168.1.3 


Any 


Any 


22.4 Table 22.3 shows a sample of a packet filter firewall ruleset for an imaginary network 
of IP address that range from 192.168.1.0 to 192.168.1.254. Describe the effect of each 
rule. 

22.5 SMTP (Simple Mail Transfer Protocol) is the standard protocol for transferring mail 
between hosts over TCP. A TCP connection is set up between a user agent and a 
server program. The server listens on TCP port 25 for incoming connection requests. 
The user end of the connection is on a TCP port number above 1023. Suppose you 
wish to build a packet filter rule set allowing inbound and outbound SMTP traffic. 
You generate the following ruleset: 


Rule | Direction | Src Addr | Dest Addr | Protocol | Dest Port | Action 
A In External Internal TCP 25 Permit 
B Out Internal External TCP >1023 Permit 
Cc Out Internal External TCP 25 Permit 
D In External Internal TCP >1023 Permit 
E Either Any Any Any Any Deny 


a. Describe the effect of each rule. 

b. Your host in this example has IP address 172.16.1.1. Someone tries to send e-mail 
from a remote host with IP address 192.168.3.4. If successful, this generates an 
SMTP dialogue between the remote user and the SMTP server on your host con- 
sisting of SMTP commands and mail. Additionally, assume that a user on your 
host tries to send e-mail to the SMTP server on the remote system. Four typical 
packets for this scenario are as shown: 


Packet | Direction Sre Addr Dest Addr | Protocol | Dest Port | Action 
1 In 192.168.3.4 172.16.1.1 TCP 25 ? 
2 Out 172.16.1.1 192.168.3.4 TCP 1234 ? 
3 Out 172.16.1.1 192.168.3.4 TCP 25 ? 
4 In 192.168.3.4 172.16.1.1 TCP 1357 ? 


Indicate which packets are permitted or denied and which rule is used in each 


case. 


22.6 
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c. Someone from the outside world (10.1.2.3) attempts to open a connection from 
port 5150 on a remote host to the Web proxy server on port 8080 on one of your 
local hosts (172.16.3.4), in order to carry out an attack. Typical packets are as 


follows: 

Packet | Direction Sre Addr Dest Addr | Protocol | Dest Port | Action 
5 In 10.1.2.3 172.16.3.4 TCP 8080 ? 
6 Out 172.16.3.4 10.1.2.3 TCP 5150 ? 


Will the attack succeed? Give details. 
To provide more protection, the ruleset from the preceding problem is modified as 


follows: 

Rule| Direction | Src Addr | Dest Addr | Protocol | Src Port | Dest Port | Action 
A In External | Internal TCP >1023 25 Permit 
B Out Internal | External TCP 25 >1023 | Permit 
Cc Out Internal | External TEP >1023 25 Permit 
D In External | Internal TCP 25 >1023 | Permit 
E Either Any Any Any Any Any Deny 


a. Describe the change. 

b. Apply this new ruleset to the same six packets of the preceding problem. Indicate 
which packets are permitted or denied and which rule is used in each case. 

A hacker uses port 25 as the client port on his or her end to attempt to open a con- 

nection to your Web proxy server. 

a. The following packets might be generated: 


Packet | Direction | Src Addr | Dest Addr | Protocol | Sre Port | Dest Port | Action 
7 In 10.1.2.3 172.16.3.4 TCP 25 8080 Z 
8 Out 172.16.3.4 10.1.2.3 TCP 8080 25 a 


Explain why this attack will succeed, using the ruleset of the preceding problem. 
b. When a TCP connection is initiated, the ACK bit in the TCP header is not set. 
Subsequently, all TCP headers sent over the TCP connection have the ACK bit 
set. Use this information to modify the ruleset of the preceding problem to 
prevent the attack just described. 
A common management requirement is that “all external Web traffic must flow via 
the organization’s Web proxy.” However, that requirement is easier stated than imple- 
mented. Discuss the various problems and issues, possible solutions, and limitations 
with supporting this requirement. In particular consider issues such as identifying 
exactly what constitutes “Web traffic” and how it may be monitored, given the large 
range of ports and various protocols used by Web browsers and servers. 
Consider the threat of “theft/breach of proprietary or confidential information held in 
key data files on the system.” One method by which such a breach might occur is 
the accidental/deliberate e-mailing of information to a user outside to the organiza- 
tion. A possible countermeasure to this is to require all external e-mail to be given a 
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22.10 


sensitivity tag (classification if you like) in its subject and for external e-mail to have 
the lowest sensitivity tag. Discuss how this measure could be implemented in a firewall 
and what components and architecture would be needed to do this. 

You are given the following “informal firewall policy” details to be implemented 
using a firewall like that in Figure 22.3: 


1. 


n 


nn 


9, 


E-mail may be sent using SMTP in both directions through the firewall, but it 
must be relayed via the DMZ mail gateway that provides header sanitization and 
content filtering. External e-mail must be destined for the DMZ mail server. 
Users inside may retrieve their e-mail from the DMZ mail gateway, using either 
POP3 or POP3S, and authenticate themselves. 

Users outside may retrieve their e-mail from the DMZ mail gateway, but only if 
they use the secure POP3 protocol, and authenticate themselves 

Web requests (both insecure and secure) are allowed from any internal user out 
through the firewall but must be relayed via the DMZ Web proxy, which provides 
content filtering (noting this is not possible for secure requests), and users must 
authenticate with the proxy for logging. 

Web requests (both insecure and secure) are allowed from anywhere on the 
Internet to the DMZ Web server 

DNS lookup requests by internal users allowed via the DMZ DNS server, which 
queries to the Internet. 

External DNS requests are provided by the DMZ DNS server. 

Management and update of information on the DMZ servers is allowed using 
secure shell connections from relevant authorized internal users (may have differ- 
ent sets of users on each system as appropriate). 

SNMP management requests are permitted from the internal management hosts 
to the firewalls, with the firewalls also allowed to send management traps (i.e., 
notification of some event occurring) to the management hosts 


Design suitable packet filter rulesets (similar to those shown in Table 22.1) to be 
implemented on the “External Firewall” and the “Internal Firewall” to satisfy the 
aforementioned policy requirements. 
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There are some dogs who wouldn't debase what are to them sacred forms. A very 
fine, very serious German Shepherd I worked with, for instance, grumbled noisily 
at other dogs when they didn’t obey. When training him to retrieve, at one point I 
set the dumbbell on its end for the fun of it. He glared disapprovingly at the 
dumbbell and at me, then pushed it carefully back into its proper position before 
picking it up and returning with it, rather sullenly. 


—Adam’s Task: Calling Animals by Name, Vicki Hearne 


The legal and ethical aspects of computer security encompass a broad range of topics, 
and a full discussion is well beyond the scope of this book. In this chapter, we touch on 
a few important topics in this area. 


23.1 CYBERCRIME AND COMPUTER CRIME 


The bulk of this book examines technical approaches to the detection, prevention, 
and recovery from computer and network attacks. One other tool is the deterrent 
factor of law enforcement. Many types of computer attacks can be considered 
crimes and, as such, carry criminal sanctions. This section begins with a classification 
of types of computer crime and then looks at some of the unique law-enforcement 
challenges of dealing with computer crime. 


Types of Computer Crime 


Computer crime, or cybercrime, is a term used broadly to describe criminal activity 
in which computers or computer networks are a tool, a target, or a place of criminal 
activity.! These categories are not exclusive, and many activities can be character- 
ized as falling in one or more categories. The term cybercrime has a connotation of 
the use of networks specifically, whereas computer crime may or may not involve 
networks. 

The U.S. Department of Justice [DOJO00] categorizes computer crime based on 
the role that the computer plays in the criminal activity, as follows: 


e Computers as targets: This form of crime targets a computer system, to 
acquire information stored on that computer system, to control the target sys- 
tem without authorization or payment (theft of service), or to alter the 
integrity of data or interfere with the availability of the computer or server. 
Using the terminology of Chapter 1, this form of crime involves an attack on 
data integrity, system integrity, data confidentiality, privacy, or availability. 


e Computers as storage devices: Computers can be used to further unlawful 
activity by using a computer or a computer device as a passive storage 
medium. For example, the computer can be used to store stolen password lists, 


'This definition is from the New York Law School Course on Cybercrime, Cyberterrorism, and Digital 
Law Enforcement (information-retrieval.info/cybercrime/index.html). 
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credit card or calling card numbers, proprietary corporate information, porno- 
graphic image files, or “warez” (pirated commercial software). 


e Computers as communications tools: Many of the crimes falling within this 
category are simply traditional crimes that are committed online. Examples 
include the illegal sale of prescription drugs, controlled substances, alcohol, 
and guns; fraud; gambling; and child pornography. 


A more specific list of crimes, shown in Table 23.1, is defined in the interna- 
tional Convention on Cybercrime.” This is a useful list because it represents an 
international consensus on what constitutes computer crime, or cybercrime, and 
what crimes are considered important. 

Yet another categorization is used in the CERT 2006 annual E-crime Survey, 
the results of which are shown in Table 23.2. The figures in the second column 
indicate the percentage of respondents who report at least one incident in the 
corresponding row category. Entries in the remaining three columns indicate 
the percentage of respondents who reported a given source for an attack.° 


Law Enforcement Challenges 


The deterrent effect of law enforcement on computer and network attacks correlates 
with the success rate of criminal arrest and prosecution. The nature of cybercrime is 
such that consistent success is extraordinarily difficult. To see this, consider what 
[KSHE06] refers to as the vicious cycle of cybercrime, involving law enforcement 
agencies, cybercriminals, and cybercrime victims (Figure 23.1). 

For law enforcement agencies, cybercrime presents some unique difficulties. 
Proper investigation requires a fairly sophisticated grasp of the technology. 
Although some agencies, particularly larger agencies, are catching up in this area, 
many jurisdictions lack investigators knowledgeable and experienced in dealing 
with this kind of crime. Lack of resources represents another handicap. Some cyber- 
crime investigations require considerable computer processing power, communica- 
tions capacity, and storage capacity, which may be beyond the budget of individual 
jurisdictions. The global nature of cybercrime is an additional obstacle: Many crimes 
will involve perpetrators who are remote from the target system, in another juris- 
diction or even another country. A lack of collaboration and cooperation with 
remote law enforcement agencies can greatly hinder an investigation. Initiatives 
such as the international Convention on Cybercrime are a promising sign. The 
Convention at least introduces a common terminology for crimes and a framework 
for harmonizing laws globally. 


The 2001 Convention on Cybercrime is the first international treaty seeking to address Internet crimes 
by harmonizing national laws, improving investigative techniques, and increasing cooperation among 
nations. It was developed by the Council of Europe and has been ratified by 43 nations, including the 
United States. The Convention includes a list of crimes that each signatory state must transpose into its 
own law. 


3Note that the sum of the figures in the last three columns for a given row may exceed 100%, because a 
respondent may report multiple incidents in multiple source categories (e.g., a respondent experiences 
both insider and outsider denial-of-service attacks). 


Article 2 IHegal access 


The access to the whole or any part of a computer system without right. 


Article 3 IHegal interception 
The interception without right, made by technical means, of non-public transmissions of computer data to, 
from or within a computer system, including electromagnetic emissions from a computer system carrying 
such computer data. 

Article 4 Data interference 
The damaging, deletion, deterioration, alteration or suppression of computer data without right. 

Article 5 System interference 
The serious hindering without right of the functioning of a computer system by inputting, transmitting, 
damaging, deleting, deteriorating, altering or suppressing computer data. 

Article 6 Misuse of devices 
a. The production, sale, procurement for use, import, distribution or otherwise making available of: 


A device, including a computer program, designed or adapted primarily for the purpose of commit- 
ting any of the offences established in accordance with the above Articles 2 through 5; 


A computer password, access code, or similar data by which the whole or any part of a computer 
system is capable of being accessed, with intent that it be used for the purpose of committing any of 
the offences established in the above Articles 2 through 5; and 


The possession of an item referred to in paragraphs a.i or ii above, with intent that it be used for the 
purpose of committing any of the offences established in the above Articles 2 through 5. A Party may 


require by law that a number of such items be possessed before criminal liability attaches. 


Article 7 Computer-related forgery 


The input, alteration, deletion, or suppression of computer data, resulting in inauthentic data with the 
intent that it be considered or acted upon for legal purposes as if it were authentic, regardless whether or 
not the data is directly readable and intelligible. 

Article 8 Computer-related fraud 


The causing of a loss of property to another person by: 
a. Any input, alteration, deletion or suppression of computer data; 


». Any interference with the functioning of a computer system, with fraudulent or dishonest intent of 
procuring, without right, an economic benefit for oneself or for another person. 
Article 9 Offenses related to child pornography 
Producing child pornography for the purpose of its distribution through a computer system; 
Offering or making available child pornography through a computer system; 
Distributing or transmitting child pornography through a computer system; 
Procuring child pornography through a computer system for oneself or for another person; 


Possessing child pornography in a computer system or on a computer-data storage medium. 


Article 10 Infringements of copyright and related rights 
Article 11 Attempt and aiding or abetting 


Aiding or abetting the commission of any of the offences established in accordance with the above 
Articles 2 through 10 of the present Convention with intent that such offence be committed. An attempt 
to commit any of the offences established in accordance with Articles 3 through 5, 7,8, and 9.1.a and c. of 
this Convention. 
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CERT 2006 E-Crime Watch Survey Results 


Committed | Insider | Outsider | Source 
(net %) (%) Unknown 
(%) 


Theft of intellectual property 


Theft of other (proprietary) info including customer 
records, financial records, etc. 


Denial of service attacks 


Virus, worms or other malicious code 


Fraud (credit card fraud, etc.) 


Identity theft of customer 


Illegal generation of spam e-mail 


Phishing (someone posing as your company online in an 
attempt to gain personal data from your subscribers or 
employees) 


Unauthorized access to/use of information, systems or 
networks 


Sabotage: deliberate disruption, deletion, or destruction 
of information, systems, or networks 


Extortion 


Web site defacement 


Zombie machines on organization’s network/bots/use of 
network by BotNets 


Intentional exposure of private or sensitive information 


Spyware (not including adware) 


Other 


The relative lack of success in bringing cybercriminals to justice has led to 
an increase in their numbers, boldness, and the global scale of their operations. 
It is difficult to profile cybercriminals in the way that is often done with other 
types of repeat offenders. The cybercriminal tends to be young and very 
computer-savvy, but the range of behavioral characteristics is wide. Further, 
there exist no cybercriminal databases that can point investigators to likely 
suspects. 

The success of cybercriminals, and the relative lack of success of law enforce- 
ment, influence the behavior of cybercrime victims. As with law enforcement, 
many organizations that may be the target of attack have not invested sufficiently 
in technical, physical, and human-factor resources to prevent attacks. Reporting 
rates tend to be low because of a lack of confidence in law enforcement, a concern 
about corporate reputation, and a concern about civil liability. The low reporting 
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Figure 23.1 The Vicious Cycle of Cybercrime 


rates and the reluctance to work with law enforcement on the part of victims feeds 
into the handicaps under which law enforcement works, completing the vicious 
cycle. 


Working With Law Enforcement 


Executive management and security administrators need to look upon law enforce- 
ment as another resource and tool, alongside technical, physical, and human-factor 
resources. The successful use of law enforcement depends much more on people 
skills than technical skills. Management needs to understand the criminal investiga- 
tion process, the inputs that investigators need, and the ways in which the victim can 
contribute positively to the investigation. 
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23.2 INTELLECTUAL PROPERTY 


The US. legal system, and legal systems generally, distinguish three primary types of 
property: 


e Real property: Land and things permanently attached to the land, such as 
trees, buildings, and stationary mobile homes. 


e Personal property: Personal effects, moveable property and goods, such as 
cars, bank accounts, wages, securities, a small business, furniture, insurance 
policies, jewelry, patents, pets, and season baseball tickets. 


e Intellectual property: Any intangible asset that consists of human knowledge 
and ideas. Examples include software, data, novels, sound recordings, the 
design of a new type of mousetrap, or a cure for a disease. 


This section focuses on the computer security aspects of intellectual property. 


Types of Intellectual Property 


There are three main types of intellectual property for which legal protection is avail- 
able: copyrights, trademarks, and patents. The legal protection is against 
infringement, which is the invasion of the rights secured by copyrights, trademarks, 
and patents. The right to seek civil recourse against anyone infringing his or her prop- 
erty is granted to the IP owner. Depending upon the type of IP, infringement may 
vary (Figure 23.2). 


Copyricuts Copyright law protects the tangible or fixed expression of an idea, 
not the idea itself. A creator can claim copyright, and file for the copyright at a 
national government copyright office, if the following conditions are fulfilled: 
e The proposed work is original. 
e The creator has put this original idea into a concrete form, such as hard copy 
(paper), software, or multimedia form. 
Examples of items that may be copyrighted include the following [BRAU01]: 


e Literary works: Novels, nonfiction prose, poetry, newspaper articles and news- 
papers, magazine articles and magazines, catalogs, brochures, ads (text), and 
compilations such as business directories 

e Musical works: Songs, advertising jingles, and instrumentals 

e Dramatic works: Plays, operas, and skits 


e Pantomimes and choreographic works: Ballets, modern dance, jazz dance, and 
mime works 


‘Copyright is automatically assigned to newly created works in countries that subscribe to the Berne 
convention, which encompasses the vast majority of nations. Some countries, such as the United States, 
provide additional legal protection if the work is registered. 
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Patents 


Unauthorized 
making, 
using or selling 


Trademarks 


Unauthorized use or 
colorable imitation 


Copyrights 


Unauthorized use 


Figure 23.2 Intellectual Property Infringement 


Pictorial, graphic, and sculptural works: Photographs, posters, maps, paintings, 
drawings, graphic art, display ads, cartoon strips and cartoon characters, 
stuffed animals, statues, paintings, and works of fine art 


Motion pictures and other audiovisual works: Movies, documentaries, travel- 
ogues, training films and videos, television shows, television ads, and interac- 
tive multimedia works 


Sound recordings: Recordings of music, sound, or words 


Architectural works: Building designs, whether in the form of architectural 
plans, drawings, or the constructed building itself 


Software-related works: Computer software, software documentation and 
manuals, training manuals, other manual 


The copyright owner has the following exclusive rights, protected against 


infringement: 


Reproduction right: Lets the owner make copies of a work 


Modification right: Also known as the derivative-works right, concerns modi- 
fying a work to create a new or derivative work 


Distribution right: Lets the owner publicly sell, rent, lease, or lend copies of 
the work. 


Public-performance right: Applies mainly to live performances 


Public-display right: Lets the owner publicly show a copy of the work directly 
or by means of a film, slide, or television image 


Parents A patent for an invention is the grant of a property right to the inventor. 
The right conferred by the patent grant is, in the language of the U.S. statute and of 
the grant itself, “the right to exclude others from making, using, offering for sale, or 
selling” the invention in the United States or “importing” the invention into the 
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United States. Similar wording appears in the statutes of other nations. There are 
three types of patents: 


e Utility patents: May be granted to anyone who invents or discovers any new 
and useful process, machine, article of manufacture, or composition of matter, 
or any new and useful improvement thereof; 


e Design patents: May be granted to anyone who invents a new, original, and 
ornamental design for an article of manufacture; and 


e Plant patents: May be granted to anyone who invents or discovers and asexu- 
ally reproduces any distinct and new variety of plant. 


An example of a patent from the computer security realm is the RSA public- 
key cryptosystem. From the time it was granted in 1983 until the patent expired in 
2000, the patent holder, RSA Security, was entitled to receive a fee for each imple- 
mentation of RSA. 


TRADEMARKS A trademark is a word, name, symbol, or device that is used in trade 
with goods to indicate the source of the goods and to distinguish them from the 
goods of others. A servicemark is the same as a trademark except that it identifies 
and distinguishes the source of a service rather than a product. The terms trademark 
and mark are commonly used to refer to both trademarks and servicemarks. 
Trademark rights may be used to prevent others from using a confusingly similar 
mark, but not to prevent others from making the same goods or from selling the 
same goods or services under a clearly different mark. 


Intellectual Property Relevant to Network 
and Computer Security 


A number of forms of intellectual property are relevant in the context of network 
and computer security. Here we mention some of the most prominent: 


e Software: This includes programs produced by vendors of commercial software 
(e.g., operating systems, utility programs, applications) as well as shareware, 
proprietary software created by an organization for internal use, and software 
produced by individuals. For all such software, copyright protection is available 
if desired. In some cases, a patent protection may also be appropriate. 


e Databases: A database may consist of data that is collected and organized 
in such a fashion that it has potential commercial value. An example is an eco- 
nomic forecasting database. Such databases may be protected by copyright. 

e Digital content: This category includes audio files, video files, multimedia, 
courseware, Web site content, and any other original digital work that can be 
presented in some fashion using computers or other digital devices. 

e Algorithms: An example of a patentable algorithm, previously cited, is the 
RSA public-key cryptosystem. 


Digital Millennium Copyright Act 


The U.S. Digital Millennium Copyright Act (DMCA) has had a profound effect on 
the protection of digital content rights in both the United States and worldwide. The 
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DMCA, signed into law in 1998, is designed to implement World Intellectual 
Property Organization (WIPO) treaties, signed in 1996. In essence, DMCA 
strengthens the protection of copyrighted materials in digital format. 

The DMCA encourages copyright owners to use technological measures to 
protect copyrighted works. These measures fall into two categories: measures that 
prevent access to the work and measures that prevent copying of the work. Further, 
the law prohibits attempts to bypass such measures. Specifically, the law states that 
“no person shall circumvent a technological measure that effectively controls access 
to a work protected under this title.” Among other effects of this clause, it prohibits 
almost all unauthorized decryption of content. The law further prohibits the manu- 
facture, release, or sale of products, services, and devices that can crack encryption 
designed to thwart either access to or copying of material unauthorized by the 
copyright holder. Both criminal and civil penalties apply to attempts to circumvent 
technological measures and to assist in such circumvention. 

Certain actions are exempted from the provisions of the DMCA and other 
copyright laws, including the following: 


e Fair use: This concept is not tightly defined. It is intended to permit others to 
perform, show, quote, copy, and otherwise distribute portions of the work for 
certain purposes. These purposes include review, comment, and discussion of 
copyrighted works. 


e Reverse engineering: Reverse engineering of a software product is allowed if 
the user has the right to use a copy of the program and if the purpose of the 
reverse engineering is not to duplicate the functionality of the program but 
rather to achieve interoperability. 


e Encryption research: “Good faith” encryption research is allowed. In essence, 
this exemption allows decryption attempts to advance the development of 
encryption technology. 


e Security testing: This is the access of a computer or network for the good faith 
testing, investigating, or correcting a security flaw or vulnerability, with the 
authorization of the owner or operator. 


e Personal privacy: It is generally permitted to bypass technological measures if 
that is the only reasonable way to prevent the access to result in the revealing 
or recording of personally identifying information. 


Despite the exemptions built into the Act, there is considerable concern, espe- 
cially in the research and academic communities, that the act inhibits legitimate secu- 
rity and encryption research. These parties feel that DMCA stifles innovation and 
academic freedom and is a threat to open source software development [ACM04]. 


Digital Rights Management 


Digital Rights Management (DRM) refers to systems and procedures that ensure 
that holders of digital rights are clearly identified and receive the stipulated pay- 
ment for their works. The systems and procedures may also impose further restric- 
tions on the use of digital objects, such as inhibiting printing or prohibiting further 
distribution. 
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There is no single DRM standard or architecture. DRM encompasses a variety of 
approaches to intellectual property management and enforcement by providing secure 
and trusted automated services to control the distribution and use of content. In 
general, the objective is to provide mechanisms for the complete content management 
life cycle (creation, subsequent contribution by others, access, distribution, use), includ- 
ing the management of rights information associated with the content. 

DRM systems should meet the following objectives: 


1. Provide persistent content protection against unauthorized access to the 
digital content, limiting access to only those with the proper authorization. 


i) 


. Support a variety of digital content types (e.g., music files, video streams, digital 
books, images). 


3. Support content use on a variety of platforms, (e.g., PCs, PDAs, iPods, mobile 
phones). 


4. Support content distribution on a variety of media, including CD-ROMs, 
DVDs, and flash memory. 


Figure 23.3, based on [LIU03], illustrates a typical DRM model in terms of the 
principal users of DRM systems: 


e Content provider: Holds the digital rights of the content and wants to protect 
these rights. Examples are a music record label and a movie studio. 


e Distributor: Provides distribution channels, such as an online shop or a Web 
retailer. For example, an online distributor receives the digital content from 


Paying distribution 


——> Information flow 


---- > Money flow 
Figure 23.3 DRM Components 
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the content provider and creates a Web catalog presenting the content and 
rights metadata for the content promotion. 


e Consumer: Uses the system to access the digital content by retrieving down- 
loadable or streaming content through the distribution channel and then pay- 
ing for the digital license. The player/viewer application used by the consumer 
takes charge of initiating license request to the clearinghouse and enforcing 
the content usage rights. 


e Clearinghouse: Handles the financial transaction for issuing the digital license 
to the consumer and pays royalty fees to the content provider and distribution 
fees to the distributor accordingly. The clearinghouse is also responsible for 
logging license consumptions for every consumer. 


In this model, the distributor need not enforce the access rights. Instead, the 
content provider protects the content in such a way (typically encryption) that the 
consumer must purchase a digital license and access capability from the clearing- 
house. The clearinghouse consults usage rules provided by the content provider to 
determine what access is permitted and the fee for a particular type of access. 
Having collected the fee, the clearinghouse credits the content provider and distrib- 
utor appropriately. 

Figure 23.4, from [[ANN06], shows a generic system architecture to support 
DRM functionality. The system is access by parties in three roles. Rights holders are 
the content providers, who either created the content or have acquired rights to the 
content. Service providers include distributors and clearinghouses. Consumers are 


Rights Service Goncuees 
holders providers 


Service interface 


Identity Content Rights 
management management management 


Systems interface 


Security | |Authentication]| Billing 
Encryption} | Authorization | |Payments 


Figure 23.4 DRM System Architecture 
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those who purchase the right to access to content for specific uses. There is system 
interface to the services provided by the DRM system: 


e Identity management: Mechanisms to uniquely identify entities, such as 
parties and content 


e Content management: Processes and functions needed to manage the content 
lifestyle 

e Rights management: Processes and functions needed to manage rights, rights 
holders, and associated requirements 


Below these management modules are a set of common functions. The 
security/encryption module provides functions to encrypt content and to sign 
license agreements. The identity management service makes use of the 
authentication and authorization functions to identify all parties in the relationship. 
Using these functions, the identity management service includes the following: 


e Allocation of unique party identifiers 
e User profile and preferences 
e User’s device management 


e Public-key management 


Billing/payments functions deal with the collection of usage fees from con- 
sumers and the distribution of payments to rights holders and distributors. Delivery 
functions deal with the delivery of content to consumers. 


23.3 PRIVACY 


An issue with considerable overlap with computer security is that of privacy. On the 
one hand, the scale and interconnectedness of personal information collected and 
stored in information systems has increased dramatically, motivated by law enforce- 
ment, national security, and economic incentives. The last mentioned has been 
perhaps the main driving force. In a global information economy, it is likely that the 
most economically valuable electronic asset is aggregations of information on individ- 
uals [JUDY09]. On the other hand, individuals have become increasingly aware of the 
extent to which government agencies, businesses, and even Internet users have access 
to their personal information and private details about their lives and activities. 

Concerns about the extent to which personal privacy has been and may be 
compromised have led to a variety of legal and technical approaches to reinforcing 
privacy rights. 


Privacy Law and Regulation 


A number of international organizations and national governments have intro- 
duced laws and regulations intended to protect individual privacy. We look at two 
such initiatives in this subsection. 


EUROPEAN UNION DATA PROTECTION DIRECTIVE In 1998, the EU adopted the 
Directive on Data Protection to both (1) ensure that member states protected 
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fundamental privacy rights when processing personal information, and (2) prevent 
member states from restricting the free flow of personal information within the EU. 
The Directive is not itself a law, but requires member states to enact laws 
encompassing its terms. The Directive is organized around the following principles 
of personal information use: 


Notice: Organizations must notify individuals what personal information they 
are collecting, the uses of that information, and what choices the individual 
may have. 


Consent: Individuals must be able to choose whether and how their personal 
information is used by, or disclosed to, third parties. They have the right not to 
have any sensitive information collected or used without express permission, 
including race, religion, health, union membership, beliefs, and sex life. 


Consistency: Organizations may use personal information only in accordance 
with the terms of the notice given the data subject and any choices with 
respect to its use exercised by the subject. 


Access: Individuals must have the right and ability to access their information 
and correct, modify, or delete any portion of it. 


Security: Organizations must provide adequate security, using technical 
and other means, to protect the integrity and confidentiality of personal 
information. 


Onward transfer: Third parties receiving personal information must provide 
the same level of privacy protection as the organization from whom the infor- 
mation is obtained. 


Enforcement: The Directive grants a private right of action to data subjects 
when organizations do not follow the law. In addition, each EU member 
has a regulatory enforcement agency concerned with privacy rights 
enforcement. 


UNITED STATES Privacy IniTrIaTives The first comprehensive privacy legislation 
adopted in the United States was the Privacy Act of 1974, which dealt with personal 
information collected and used by federal agencies. The Act is intended to 


1. 
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Permit individuals to determine what records pertaining to them are collected, 
maintained, used, or disseminated. 


Permit individuals to forbid records obtained for one purpose to be used for 
another purpose without consent. 


Permit individuals to obtain access to records pertaining to them and to correct 
and amend such records as appropriate. 


Ensure that agencies collect, maintain, and use personal information in a manner 
that ensures that the information is current, adequate, relevant, and not excessive 
for its intended use. 


Create a private right of action for individuals whose personal information is 
not used in accordance with the Act. 
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As with all privacy laws and regulations, there are exceptions and conditions 
attached to this Act, such as criminal investigations, national security concerns, and 
conflicts between competing individual rights of privacy. 

While the 1974 Privacy Act covers government records, a number of other U.S. 
laws have been enacted that cover other areas, including the following: 


e Banking and financial records: Personal banking information is protected in 
certain ways by a number of laws, including the recent Financial Services 
Modernization Act. 


e Credit reports: The Fair Credit Reporting Act confers certain rights on indi- 
viduals and obligations on credit reporting agencies. 


¢ Medical and health insurance records: A variety of laws have been in place for 
decades dealing with medical records privacy. The Health Insurance 
Portability and Accountability Act (HIPPA) created significant new rights for 
patients to protect and access their own health information. 


e Children’s privacy: The Children’s Online Privacy Protection Act places 
restrictions on online organizations in the collection of data from children 
under the age of 13. 


e Electronic communications: The Electronic Communications Privacy Act 
generally prohibits unauthorized and intentional interception of wire and 
electronic communications during the transmission phase and unauthorized 
accessing of electronically stored wire and electronic communications. 


Organizational Response 


Organizations need to deploy both management controls and technical measures to 
comply with laws and regulations concerning privacy as well as to implement corpo- 
rate policies concerning employee privacy. ISO 17799 (Code of Practice for 
Information Security Management) states the requirement as follows: 


ISO 17799: Data protection and privacy of personal 
information 


An organizational data protection and privacy policy should be developed and 
implemented. This policy should be communicated to all persons involved in the 
processing of personal information. Compliance with this policy and all relevant 
data protection legislation and regulations requires appropriate management 
structure and control. Often this is best achieved by the appointment of a 
responsible person, such as a data protection officer, who should provide guid- 
ance to managers, users, and service providers on their individual responsibilities 
and the specific procedures that should be followed. Responsibility for handling 
personal information and ensuring awareness of the data protection principles 
should be dealt with in accordance with relevant legislation and regulations. 
Appropriate technical and organizational measures to protect personal informa- 
tion should be implemented. 
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Privacy and Data Surveillance 


The demands of homeland security and counterterrorism have imposed new threats 
to personal privacy. Law enforcement and intelligence agencies have become 
increasingly aggressive in using data surveillance techniques to fulfill their mission. 
In addition, private organization are exploiting a number of trends to increase their 
ability to build detailed profiles of individuals, including the spread of the Internet, 
the increase in electronic payment methods, near-universal use of cellular phone 
communications, ubiquitous computation, sensor webs, and so on. 

Both policy and technical approaches are needed to protect privacy when both 
government and nongovernment organizations seek to learn as much as possible 
about individuals. In terms of technical approaches, the requirements for privacy 
protection for information systems can be addressed in the context of database 
security. That is, the approaches that are appropriate for privacy protection involve 
technical means that have been developed for database security. 

A specific proposal for a database security approach to privacy protection is 
outlined in [POPP06] and illustrated in Figure 23.5. The privacy appliance is a tam- 
per-resistant, cryptographically protected device that is interposed between a data- 
base and the access interface, analogous to a firewall or intrusion prevention device. 
The device implements privacy protection functions, including verifying the user’s 
access permissions and credentials and creating an audit log. Some of the specific 
functions of the appliance are as follows: 


e Data transformation: This function encodes or encrypts portions of the data so 
as to preserve privacy but still allow data analysis functions needed for effec- 
tive use. An example of such data analysis functions is the detection of terror- 
ist activity patterns. 


e Anonymization: This function removes specific identifying information from 
query results, such as last name and telephone number, but creates some sort 
of anonymized unique identifier so that analysts can detect connections 
between queries. 


e Selective revelation: This is a method for minimizing exposure of individual 
information while enabling continuous analysis of potentially interconnected 
data. The function initially reveals information to the analyst only in sanitized 
form, that is, in terms of statistics and categories that do not reveal (directly or 
indirectly) anyone’s private information. If the analyst sees reason for 
concern, he or she can follow up by seeking permission to get more precise 
information. This permission would be granted if the initial information 
provides sufficient cause to allow the revelation of more information, under 
appropriate legal and policy guidelines. 


e Immutable audit: A tamper-resistant method that identifies where data go and 
who has seen the data. The audit function automatically and permanently 
records all data accesses, with strong protection against deletion, modification, 
and unauthorized use. 


e Associative memory: This is a software module that can recognize patterns 
and make connections between pieces of data that the human user may have 
missed or didn’t know existed. With this method, it can discover relationships 
quickly between data points found in massive amounts of data. 


LI-¢7@ 


® Contains associative memory index (AMI) 
e Update in real time 


Privacy Data 
appliance source 


ae 
Privacy Data 


appliance source 


Cross-source 
privacy 
appliance 


Privacy 
Independently \ appliance 


operated 


Data 
source 


Government 
owned 


Private or 
agency owned 


e Authentication e Selective revelation 
e Authorization e Data transformation 
e Anonymization e Policy is embedded 
e Immutable audit trail e Create AMI 

e Inference checking 


Figure 23.5 Privacy Appliance Concept 
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As Figure 23.5 indicates, the owner of a database installs a privacy appliance 
tailored to the database content and structure and to its intended use by outside 
organizations. An independently operated privacy appliance can interact with multi- 
ple databases from multiple organizations to collect and interconnect data for their 
ultimate use by law enforcement, an intelligence user, or other appropriate user. 


23.4 ETHICAL ISSUES 


Because of the ubiquity and importance of information systems in organizations of 
all types, there are many potential misuses and abuses of information and electronic 
communication that create privacy and security problems. In addition to questions 
of legality, misuse and abuse raise concerns of ethics. Ethics refers to a system of 
moral principles that relates to the benefits and harms of particular actions, and to 
the rightness and wrongness of motives and ends of those actions. In this section, we 
look at ethical issues as they relate to computer and information system security. 


Ethics and the IS Professions 


To a certain extent, a characterization of what constitutes ethical behavior for those 
who work with or have access to information systems is not unique to this context. 
The basic ethical principles developed by civilizations apply. However, there are 
some unique considerations surrounding computers and information systems. First, 
computer technology makes possible a scale of activities not possible before. This 
includes a larger scale of recordkeeping, particularly on individuals, with the ability 
to develop finer-grained personal information collection and more precise data 
mining and data matching. The expanded scale of communications and the 
expanded scale of interconnection brought about by the Internet magnify the power 
of an individual to do harm. Second, computer technology has involved the creation 
of new types of entities for which no agreed ethical rules have previously been 
formed, such as databases, Web browsers, chat rooms, cookies, and so on. 

Further, it has always been the case that those with special knowledge or spe- 
cial skills have additional ethical obligations beyond those common to all humanity. 
We can illustrate this in terms of an ethical hierarchy (Figure 23.6), based on one 
discussed in [GOTT99]. At the top of the hierarchy are the ethical values profes- 
sionals share with all human beings, such as integrity, fairness, and justice. Being a 
professional with special training imposes additional ethical obligations with respect 
to those affected by his or her work. General principles applicable to all profession- 
als arise at this level. Finally, each profession has associated with it specific ethical 
values and obligations related to the specific knowledge of those in the profession 
and the powers that they have to affect others. Most professions embody all of these 
levels in a professional code of conduct, a subject discussed subsequently. 


Ethical Issues Related to Computers 
and Information Systems 


Let us turn now more specifically to the ethical issues that arise from computer 
technology. Computers have become the primary repository of both personal 
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Figure 23.6 The Ethical Hierarchy 


information and negotiable assets, such as bank records, securities records, and other 
financial information. Other types of databases, both statistical and otherwise, are 
assets with considerable value. These assets can only be viewed, created, and altered 
by technical and automated means. Those who can understand and exploit the 
technology, plus those who have obtained access permission, have power related to 
those assets. 

A classic paper on computers and ethics [PARK88b] points out that ethical 
issues arise as the result of the roles of computers, such as the following: 


e Repositories and processors of information: Unauthorized use of otherwise 
unused computer services or of information stored in computers raises ques- 
tions of appropriateness or fairness. 


e Producers of new forms and types of assets: For example, computer programs 
are entirely new types of assets, possibly not subject to the same concepts of 
ownership as other assets. 


e Instruments of acts: To what degree must computer services and users of 
computers, data, and programs be responsible for the integrity and appropri- 
ateness of computer output? 


e Symbols of intimidation and deception: The images of computers as thinking 
machines, absolute truth producers, infallible, subject to blame, and as anthro- 
pomorphic replacements of humans who err should be carefully considered. 
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Table 23.3. Potential Ethical Dilemmas for Information Systems 


Technology Intrusion Computer surveillance 


Privacy internal to the firm 


Privacy external to the firm 


Employee monitoring 


Hacking 


Ownership Issues 


Moonlighting 

Proprietary rights 

Conflicts of interest 

Software copyrights 

Use of company assets for personal benefit 


Theft of data, software, or hardware 


Legal Issues and Social Responsibilities 


Embezzlement, fraud and abuse, such as through EFTs or ATMs 
Accuracy and timeliness of data 
Over-rated system capabilities and “smart” computers 


Monopoly of data 


Personnel Issues Ergonomics and human factors 


Employee sabotage 


Training to avoid job obsolescence 


Another listing of ethical issues, from [HARR90], is shown in Table 23.3. Both 
of these lists are concerned with balancing professional responsibilities with ethical 
or moral responsibilities. We cite two areas here of the types of ethical questions 
that face a computing or IS professional. The first is that IS professionals may find 
themselves in situations where their ethical duty as professionals comes into conflict 
with loyalty to their employer. Such a conflict may give rise for an employee to con- 
sider “blowing the whistle,” or exposing a situation that can harm the public or a 
company’s customers. For example, a software developer may know that a product 
is scheduled to ship with inadequate testing to meet the employer’s deadlines. The 
decision of whether to blow the whistle is one of the most difficult that an IS profes- 
sional can face. Organizations have a duty to provide alternative, less extreme 
opportunities for the employee, such as an in-house ombudsperson coupled with a 
commitment not to penalize employees for exposing problems in-house. 
Additionally, professional societies should provide a mechanism whereby society 
members can get advice on how to proceed. 

Another example of an ethical question concerns a potential conflict of inter- 
est. For example, if a consultant has a financial interest in a certain vendor, 
this should be revealed to any client if that vendor’s products or services might be 
recommended by the consultant. 


Codes of Conduct 


Unlike scientific and engineering fields, ethics cannot be reduced to precise laws or 
sets of facts. Although an employer or a client of a professional can expect that the 
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professional has an internal moral compass, many areas of conduct may present eth- 
ical ambiguities. To provide guidance to professionals and to articulate what 
employers and customers have a right to expect, a number of professional societies 
have adopted ethical codes of conduct. 

A professional code of conduct can serve the following functions [GOTT99]: 


1. A code can serve two inspirational functions: as a positive stimulus for ethical 
conduct on the part of the professional, and to instill confidence in the cus- 
tomer or user of an IS product or service. However, a code that stops at just 
providing inspirational language is likely to be vague and open to an abun- 
dance of interpretations. 


N 


. A code can be educational. It informs professionals about what should be their 
commitment to undertake a certain level of quality of work and their responsibil- 
ity for the well being of users of their product and the public, to the extent the 
product may affect nonusers. The code also serves to educate managers on their 
responsibility to encourage and support employee ethical behavior and on their 
own ethical responsibilities. 

3. A code provides a measure of support for a professional whose decision to act 

ethically in a situation may create conflict with an employer or customer. 

4. A code can be a means of deterrence and discipline. A professional society can 

use a code as a justification for revoking membership or even a professional 

license. An employee can use a code as a basis for a disciplinary action. 


a) 
. 


A code can enhance the profession’s public image, if it is seen to be widely 
honored. 


We illustrate the concept of a professional code of ethics for computer profes- 
sionals with three specific examples. The ACM (Association for Computing 
Machinery) Code of Ethics and Professional Conduct (Figure 23.7) applies to com- 
puter scientists.° The IEEE (Institute of Electrical and Electronics Engineers) Code 
of Ethics (Figure 23.8) applies to computer engineers as well as other types of elec- 
trical and electronic engineers. The AITP (Association of Information Technology 
Professionals, formerly the Data Processing Management Association) Standard of 
Conduct (Figure 23.9) applies to managers of computer systems and projects. 

A number of common themes emerge from these codes, including (1) dignity 
and worth of other people; (2) personal integrity and honesty; (3) responsibility for 
work; (4) confidentiality of information; (5) public safety, health, and welfare; (6) 
participation in professional societies to improve standards of the profession; and 
(7) the notion that public knowledge and access to technology is equivalent to 
social power. 

All three codes place their emphasis on the responsibility of professionals to 
other people, which, after all, is the central meaning of ethics. This emphasis on peo- 
ple rather than machines or software is to the good. However, the codes make little 
specific mention of the subject technology, namely computers and information 


>Figure 23.7 is an abridged version of the ACM Code. 


1. GENERAL MORAL IMPERATIVES. 


1.1 Contribute to society and human well-being. 

1.2 Avoid harm to others. 

1.3 Be honest and trustworthy. 

1.4 Be fair and take action not to discriminate. 

1.5 Honor property rights including copyrights and patent. 
1.6 Give proper credit for intellectual property. 

1.7 Respect the privacy of others. 

1.8 Honor confidentiality. 


2. MORE SPECIFIC PROFESSIONAL RESPONSIBILITIES. 


2.1 Strive to achieve the highest quality, effectiveness and dignity in both the process and 
products of professional work. 

2.2 Acquire and maintain professional competence. 

2.3 Know and respect existing laws pertaining to professional work. 

2.4 Accept and provide appropriate professional review. 

2.5 Give comprehensive and thorough evaluations of computer systems and their 
impacts, including analysis of possible risks. 

2.6 Honor contracts, agreements, and assigned responsibilities. 

2.7 Improve public understanding of computing and its consequences. 

2.8 Access computing and communication resources only when authorized to do so. 


3. ORGANIZATIONAL LEADERSHIP IMPERATIVES. 


3.1 Articulate social responsibilities of members of an organizational unit and encourage 
full acceptance of those responsibilities. 

3.2 Manage personnel and resources to design and build information systems that 
enhance the quality of working life. 

3.3 Acknowledge and support proper and authorized uses of an organization’s comput- 
ing and communication resources. 

3.4 Ensure that users and those who will be affected by a system have their needs clearly 
articulated during the assessment and design of requirements; later the system must be 
validated to meet requirements. 

3.5 Articulate and support policies that protect the dignity of users and others affected 
by a computing system. 

3.6 Create opportunities for members of the organization to learn the principles and 
limitations of computer systems. 


4. COMPLIANCE WITH THE CODE. 


4.1 Uphold and promote the principles of this Code. 
4.2 Treat violations of this code as inconsistent with membership in the ACM. 


Figure 23.7 ACM Code of Ethics and Professional Conduct 
(Copyright ©1997, Association for Computing Machinery, Inc.) 


systems. That is, the approach is quite generic and could apply to most professions 
and does not fully reflect the unique ethical problems related to the development 
and use of computer and IS technology. For example, these codes do not specifically 
deal with the issues raised in Table 23.3 or by [PARK88b] listed in the preceding 
subsection. 


We, the members of the IEEE, in recognition of the importance of our technologies in 
affecting the quality of life throughout the world, and in accepting a personal obligation 
to our profession, its members and the communities we serve, do hereby commit our- 
selves to the highest ethical and professional conduct and agree: 


1. to accept responsibility in making decisions consistent with the safety, health and 
welfare of the public, and to disclose promptly factors that might endanger the 
public or the environment; 

2. to avoid real or perceived conflicts of interest whenever possible, and to disclose 
them to affected parties when they do exist; 

3. to be honest and realistic in stating claims or estimates based on available data; 
to reject bribery in all its forms; 

5. to improve the understanding of technology, its appropriate application, and 
potential consequences; 

6. to maintain and improve our technical competence and to undertake technological 
tasks for others only if qualified by training or experience, or after full disclosure of 
pertinent limitations; 

. to seek, accept, and offer honest criticism of technical work, to acknowledge and 
correct errors, and to credit properly the contributions of others; 

8. to treat fairly all persons regardless of such factors as race, religion, gender, 
disability, age, or national origin; 

9. to avoid injuring others, their property, reputation, or employment by false or 
malicious action; 

. to assist colleagues and co-workers in their professional development and to 
support them in following this code of ethics 


p .8 IEEE Code of Ethics 
(Copyright ©2006, Institute of Electrical and Electronics Engineers) 


Kigure 2 


In recognition of my obligation to management I shall: 


Keep my personal knowledge up-to-date and insure that proper expertise is available when 
needed. 


Share my knowledge with others and present factual and objective information to 
management to the best of my ability. 


Accept full responsibility for work that I perform. 
Not misuse the authority entrusted to me. 


Not misrepresent or withhold information concerning the capabilities of equipment, software 
or systems. 


Not take advantage of the lack of knowledge or inexperience on the part of others. 
In recognition of my obligation to my fellow members and the profession I shall: 


Be honest in all my professional relationships. 


Take appropriate action in regard to any illegal or unethical practices that come to my atten- 
tion. However, I will bring charges against any person only when I have reasonable basis for 
believing in the truth of the allegations and without any regard to personal interest. 


Endeavor to share my special knowledge. 
Cooperate with others in achieving understanding and in identifying problems. 


(continued) 


Figure 23.9 AITP Standard of Conduct 
(Copyright ©2006, Association of Information Technology Professionals) 
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Not use or take credit for the work of others without specific acknowledgement and 
authorization. 


Not take advantage of the lack of knowledge or inexperience on the part of others for 
personal gain. 


In recognition of my obligation to society I shall: 


Protect the privacy and confidentiality of all information entrusted to me. 
Use my skill and knowledge to inform the public in all areas of my expertise. 


To the best of my ability, insure that the products of my work are used in a socially 
responsible way. 


Support, respect, and abide by the appropriate local, state, provincial, and federal laws. 


Never misrepresent or withhold information that is germane to a problem or situation of 
public concern nor will I allow any such known information to remain unchallenged. 


Not use knowledge of a confidential or personal nature in any unauthorized manner or to 
achieve personal gain. 

In recognition of my obligation to my employer I shall: 
Make every effort to ensure that I have the most current knowledge and that the proper 
expertise is available when needed. 
Avoid conflict of interest and insure that my employer is aware of any potential conflicts. 
Present a fair, honest, and objective viewpoint. 
Protect the proper interests of my employer at all times. 
Protect the privacy and confidentiality of all information entrusted to me. 
Not misrepresent or withhold information that is germane to the situation. 


Not attempt to use the resources of my employer for personal gain or for any purpose 
without proper approval. 


Not exploit the weakness of a computer system for personal gain or personal satisfaction. 


Figure 23.9 Continued 


23.5 RECOMMENDED READING AND WEB SITES 


The following are useful articles on computer crime and cybercrime: [KSHE06], 
[CYMRO6], and [TAVA00]. [BRAU01] provides a good introduction to copyrights, 
patents, and trademarks. [GIBBOO] provides a concise description of the Digital 
Millennium Copyright Act. A useful introduction to Digital Rights Management is 
[LIU03]. [CAMP03] discusses legal aspects of DRM and describes some commercially 
available systems. 

[ISAT02] is an illuminating discussion of the relationship between security and 
privacy with suggestions on technical security measures to protect privacy. [GOTT99] 
provides a detailed discussion of the software engineering code of ethics and what it 
means to individuals in the profession. [CHAP06] is a thoughtful discussion of basic ethi- 
cal issues related to the creation and use of information systems. [HARR90] is a detailed 
discussion of training employees on how to integrate ethics into decision making and 
behavior related to the use of information systems and computers. [ANDE93] is a very 
useful analysis of the practical implications of the ACM Code of Ethics, with a number of 
illustrative case studies. 
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Recommended Web Sites: 


e Criminal Justice Resources: CyberCrime: Excellent collection of links maintained by 
Michigan State University. 


e International High Technology Crime Investigation Association: A collaborative effort of 
law enforcement and the private sector. Contains useful set of links and other resources. 


e Computer Ethics Institute: Includes documents, case studies, and links. 
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Key Terms 


code of conduct digital rights management patent 
computer crime ethics privacy 


copyright 


infringement trademark 


cybercrime intellectual property 
Digital Millennium Copyright 


Act (DMCA) 
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Review Questions 
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Describe a classification of computer crime based on the role that the computer plays 
in the criminal activity. 


Define three types of property. 

Define three types of intellectual property. 

What are the basic conditions that must be fulfilled to claim a copyright? 

What rights does a copyright confer? 

Briefly describe the Digital Millennium Copyright Act. 

What is digital rights management? 

Describe the principal categories of users of digital rights management systems. 
What are the key principles embodied in the EU Directive on Data Protection? 
What functions can a professional code of conduct serve to fulfill? 


Problems 
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For each of the cybercrimes cited in Table 23.1, indicate whether it falls into the cate- 
gory of computer as target, computer as storage device, or computer as communica- 
tions tool. In the first case, indicate whether the crime is primarily an attack on data 
integrity, system integrity, data confidentiality, privacy, or availability. 

Repeat Problem 23.1 for Table 23.2. 


Review the results of a recent Computer Crime Survey such as the CSI/FBI or 
AusCERT surveys. What changes do they note in the types of crime reported? What 
differences are there between their results and those shown in Table 23.2? 


An early controversial use of the DCMA was its use in a case in the United States 
brought by the Motion Picture Association of America (MPAA) in 2000 to attempt to 
suppress distribution of the DeCSS program and derivatives. These could be used cir- 
cumvent the copy protection on commercial DVDs. Search for a brief description of 
this case and its outcome. Determine whether the MPAA was successful in suppress- 
ing details of the DeCSS descrambling algorithm. 


Consider a popular DRM system like Apple’s FairPlay, used to protect audio tracks 
purchased from the iTunes music store. If a person purchases a track from the iTunes 
store by an artist managed by a record company such as EMI, identify which com- 
pany or person fulfils each of the DRM component roles shown in Figure 23.3. 


Table 23.4 lists the privacy guidelines issued by the Organization for Economic 
Cooperation and Development (OECD). Compare these guidelines to the categories 
the EU adopted in the Directive on Data Protection. 


Many countries now require organizations that collect personal information to pub- 
lish a privacy policy detailing how they will handle and use such information. Obtain 
a copy of the privacy policy for an organization to which you have provided your per- 
sonal details. Compare this policy with the lists of principles given in Section 23.3. 
Does this policy address all of these principles? 


Assume you are a midlevel systems administrator for one section of a larger organi- 
zation. You try to encourage your users to have good password policies and you regu- 
larly run password-cracking tools to check that those in use are not guessable. You 
have become aware of a burst of hacker password-cracking activity recently. In a 
burst of enthusiasm you transfer the password files from a number of other sections 
of the organization and attempt to crack them. To your horror, you find that in one 
section for which you used to work (but now have rather strained relationships with), 
something like 40% of the passwords are guessable (including that of the vice- 
president of the section, whose password is “pre$ident”!). You quietly sound out a 
few former colleagues and drop hints in the hope things might improve. A couple of 
weeks later you again transfer the password file over to analyze in the hope things 
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Table 23.4 OECD Guidelines on the Protection of Privacy and Transborder Flows of Information 


Collection limitation 


There should be limits to the collection of personal data and any such data should be obtained by lawful 
and fair means and, where appropriate, with the knowledge or consent of the data subject. 


Data quality 


Personal data should be relevant to the purposes for which they are to be used, and, to the extent 
necessary for those purposes, should be accurate, complete and kept up-to-date. 


Purpose specification 


The purposes for which personal data are collected should be specified not later than at the time of data 
collection and the subsequent use limited to the fulfillment of those purposes or such others as are not 
incompatible with those purposes and as are specified on each occasion of change of purpose. 

Use limitation 


Personal data should not be disclosed, made available or otherwise used for purposes other than those 
specified in accordance with the preceding principle, except with the consent of the data subject or by the 
authority of law. 

Security safeguards 
Personal data should be protected by reasonable security safeguards against such risks as loss or unautho- 
rized access, destruction, use, modification or disclosure of data. 

Openness 


There should be a general policy of openness about developments, practices and policies with respect to 

personal data. Means should be readily available of establishing the existence and nature of personal 

data, and the main purposes of their use, as well as the identity and usual residence of the data controller. 
Individual participation 


An individual should have the right: 
(a) to obtain from a data controller, or otherwise, confirmation of whether or not the data controller 
has data relating to him. 


(b) to have communicated to him, data relating to him within a reasonable time; at a charge, if any, 
that is not excessive; in a reasonable manner; and in a form that is readily intelligible to him; 


(c) to be given reasons if a request made under subparagraphs(a) and (b) is denied, and to be able to 
challenge such denial; and 


(d) to challenge data relating to him and, if the challenge is successful to have the data erased, 
rectified, completed or amended. 


Accountability 


A data controller should be accountable for complying with measures which give effect to the principles 
stated above. 


have improved. They haven’t. Unfortunately, this time one of your colleagues notices 
what you are doing. Being a rather “by the book” person, he notifies senior manage- 
ment, and that evening you find yourself being arrested on a charge of hacking and 
thrown out of a job. Did you do anything wrong? Which of the potential ethical dilem- 
mas listed in Table 23.3 does this case illustrate? Briefly indicate what arguments you 
might use to defend your actions, Make reference to the Professional Codes of 
Conduct shown in Figures 23.7 through 23.9. 

23.9 Section 23.4 stated that the three ethical codes illustrated in this chapter (ACM, 
IEEE, AITP) share the common themes of dignity and worth of people; personal 
integrity; responsibility for work; confidentiality of information; public safety, health, 
and welfare; participation in professional societies; and knowledge about technology 
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23.10 


related to social power. Construct a table that shows for each theme and for each 

code, the relevant clause or clauses in the code that address the theme. 

This book’s Web site includes a copy of the ACM Code of Professional Conduct from 

1982. Compare this Code with the 1997 ACM Code of Ethics and Professional 

Conduct (Figure 23.7). 

a. Are there any elements in the 1982 Code not found in the 1997 Code? Propose a 
rationale for excluding these. 

b. Are there any elements in the 1997 Code not found in the 1982 Code? Propose a 
rationale for adding these. 

This book’s Web site includes a copy of the IEEE Code of Ethics from 1979. Compare 

this Code with the 2006 IEEE Code of Ethics (Figure 23.8). 

a. Are there any elements in the 1979 Code not found in the 2006 Code? Propose a 
rationale for excluding these. 

b. Are there any elements in the 2006 Code not found in the 1979 Code? Propose a 
rationale for adding these. 

This book’s Web site includes a copy of the 1999 Software Engineering Code of Ethics 

and Professional Practice (Version 5.2) as recommended by an ACM/IEEE-CS Joint 

Task Force. Compare this Code with each of the three codes reproduced in this 

chapter (Figure 23.7 through 23.9). Comment in each case on the differences. 
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This appendix contains a number of exercises that reinforce cryptographic concepts, 
organized by the chapter in which those concepts were discussed. All the exercises 
use Sage. We begin with a discussion of how to get started using Sage and a brief 
introduction to the syntax and operations. 


GETTING STARTED WITH SAGE 


Sage is a free open source program that collects many open source math packages 
into one easily usable environment. 

The following are step-by-step instructions to installing and getting started 
using Sage for the examples and exercises in this book.! 


1. Go to http://www.sagemath.org/download/ 
2. You have two options: 
a. Building from source: If you are well versed in compilers and building soft- 
ware, you can build from source. Select this option. 
b. Installing Binaries: You can install precompiled binaries, the process is dif- 
ferent on several different operating systems. 


e Linux Download the Linux binaries, download, and follow the instructions 
in the README file. 

e Mac OS X Download the Mac OS X binaries and follow the instructions in 
the README file. 

e Windows: With Windows the process is a little bit more complicated. At the 
time of printing the only complete option for Sage on Windows requires 
running ubuntu in a virtual machine. The directions are contained in the 
windows section of the download. However, copied here for reference they 
are: 

i) Download the VMWare player: http://www.vmware.com/products/player/ 
(this is a free download for students / educators.) 
ii) Download the VMWare image from the Sage website and follow the 
directions in the README file. 
There is also a native port of windows, in progress, at the time of this 
printing. You can try it and see if it works for your purposes at: 
http://windows.sagemath.com 
3. Once you have Sage installed, On Linux or Mac OS X you can just type Sage 
from a shell prompt and it will run the interpreter (if you installed the 

Sage script in the correct location, as in the README files.) On windows, you 

run Sage by starting the VMWare player to open the Sage virtual hard drive. 

Once the VMWare player is started, you can use the player to enter data into 

the command line, you can SSH to your virtual machine (useful for copy and 

paste functionality) and use the notebook. 
4. Sage also has notebook functionality, similar to that of Maple or Mathemati- 

ca worksheets. This runs through the web browser. On Linux and Mac OS xX, 


'Please note that Sage is an open source package that is constantly under development, and much func- 
tionality changes from release to release. If any of the steps in this section do not work, please check 
http://www.sagemath.org for new up-to-date information. 
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you start the notebook by typing notebook() from the command prompt, or 
by running Sage with the -notebook argument. In the VMWare image, this is 
run by selecting notebook from the login options when the VMWare image 
starts up. 
If you wish to execute the Sage examples from Appendix B, you can now 
download the relevant Sage files.? If you are using a Linux or Mac OS X 
machine, then you just download your files to a folder and run Sage to access 
them. However, if you are using the VMWare player then you need to get the 
files into your virtual machine. This can be done using the shared folder’s 
option in VMWare player, or copying the files using wget or scp from inside 
the virtual machine. You can access the underlying Ubuntu operating system 
in the Sage virtual machine by selecting the manage option when the VMWare 
image starts up. 

6. As mentioned in step 3, Sage is an interpreted language, and you interact with 
it through a prompt. However you can also write batch scripts. These files have 
the suffix .sage and each line is a line that you would type into the interpreter. 
You can load these into the interpreter by using the “load” and “attach” 
commands. The command “load” runs the file once. On the other hand, the 
command “attach” monitors the underlying .sage file and reloads it if there are 
any changes. 

7. The Sage interpreter keeps track of your underlying path, running attach and 
load is relative to this path. You can change the current path by using ‘cd’ like 
you would in a shell. Suppose that you want to run a file example.sage, you can 
do this by typing: 


7) 
. 


load example.sage 


While the current directory of the Sage interpreter is the directory containing 
example.sage. 


There is significantly more information and documentation on Sage and how 
to run it at http://www.sagemath.org/doc. This page includes a tutorial, a reference 
manual, a Sage programmer’s manual, and an installation guide. See this documen- 
tation for the most up to date information on Sage. Even more documentation and 
help is available at http://www.sagemath.org/help.html. Particularly worthwhile is 
the downloadable book Sage for Newbies. 

Sage is a rich, powerful facility, and the amount of documentation may seem 
overwhelming. However, if you study the examples in Appendix B and the discus- 
sion in this section and the next, you should be able to write Sage code to solve the 
problems with little reference to the documentation. Furthermore, any time devoted 
to learning Sage is a worthwhile investment, because Sage is a general-purpose 
mathematical tool that you will be able to use throughout your academic and 
professional career. 


7All of the Sage code in Appendix B is available online at this book’s Web site in .sage files, so that you 
can load and execute the programs if you wish. See Preface for access information. 
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C.2 PROGRAMMING WITH SAGE 


The following is a basic introduction to Sage programming. Sage is a collection of 
open source mathematics packages that are loaded into a Python interpreter. Input 
to Sage is lightly preprocessed and sent to a Python interpreter. Thus, all program- 
ming in Sage is essentially just Python programming. Readers familiar with Python 
can skip much of this section, however Sage does modify the Python environment 
some, so reading some of the sections especially about numeric data types may be 
useful. The following are some of the basic Sage programming constructs.* 


Input to the Interpreter 


Python is an interpreted language, so you can interact with the program line by line. 

Python is object-oriented, so as long as you are not using built in data types, you 
can use the following technique to learn about the member functions and variables 
of the class you are working with. Suppose foo is a variable of FooClass type, then 
typing foo. <tab>, (<tab> means, hit tab) will auto complete. If you begin typing the 
name of a variable, hitting tab will list all members that start with what you have 
already typed, if there is only one such member, it will autocomplete. 

Suppose foo has a member bar, to learn about this member, you can type 
foo.bar? and hit enter, this will display documentation on the function bar if it 
exists. You can also type foo.bar?? and hit enter to display the documentation 
and the source code. 

You can also use the print function to try to print a Sage object. So if foo is some 
variable, the expression print foo will try to convert foo into a string and print it. 

Also the function type (foo) will return the type of the variable foo, which is 
also useful. 


Data Types 


One basic data type is Str. This is the built-in data type for strings in Python. They are 
entered into the interpreter by putting a literal string in single quotes '' or double 
quotes "". These are sequential, and can be accessed as such. For example if foo = 
'foo', then £oo[0] = '£' and foo[1]='o'. 

Sage provides the following numeric data types. 


e int: This is the built-in, fixed precision signed integer data type of Python. 
This is the default data type used to access sequential data (like tuples and 
lists) as well as the default loop counter. 

® long: This is the built-in, arbitrary precision integer data type of Python. If an 
operation on operands of type int overflows, the result will be a long. 

° Integer: This is a Sage data type that implements arbitrary precision 
integers. This is the default type ascribed to integers typed into the Sage 
interpreter. The object for the integers is ZZ. Variables of type int or long 
can be cast to an Integer as follows, if foo is an int or a long then 
ZZ (£00) casts foo to an Integer. (Integer (foo) will work as well.) 


3Note that Sage does change from release to release, so be sure to check http://www.sagemath.org/doc for 
the most up to date documentation. 
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e Rational: This is the Sage data type that implements arbitrary precision 
rational numbers. If you type something like 2/3 into the Sage interpreter, this is 
the default type that the value will be given. The object for the rational numbers 
is QQ. Variables of type int, long, or Integer can be cast to a Rational as 
follows, if foo is such a numeric type, then QQ (foo) casts foo to a Rational. 
(Rational (foo) will work as well.) This is important to bear in mind, as in 
many programming languages 2/3 would evaluate to the integer 0. 


Two important sequential data types in Sage are list and tuple. The list 
type is the built-in Sage type for lists (arrays). The syntax for lists is an open and 
close square brackets, with items separated by commas. 


e The empty list is 
foo = [] 

e A list of the first three integers is 
foo = [1, 2, 3] 


e A list of some different types is 


foo = ['2/3’, 2, 2/3] 


The first element is a string, the second is an Integer and the third is a 
Rational. 


The function range([start,] end) returns the list of integers from start 
through end-1. If start is omitted 0 is assumed. Also, you can initiate a list with a 
variable number of arguments explicitly by doing: 


foo = [<expression in j> for j in xrange(M) ] 


Where M is some integral data type, and <expression in j> is some Python 
expression that is allowed to reference the loop counter j. You access list elements 
by square brackets after the name of the variable, so foo[i] returns the ith 
element of a list. Lists are mutable, so you can assign values to the elements as 
follows: foo[i] = bar. You can also extend lists by using the append function, as 
in: foo.append (bar). You can get a length of a list with the built in function 
len(...), by calling it as len(foo). 

The tuple data type is the built in Sage type for immutable lists of elements. 
They syntax is like that for lists but parenthesis are used instead of square brackets. 
As with the examples for lists: 


e The empty tuple is 
foo = () 

e A tuple of the first three integers is 
foo = (1, 2, 3) 

e A tuple of some different types is 
foo = (*2/3", 2, 2/3) 
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Tuples are accessed just as lists,so foo [i] returns the ith element of the tuple £oo. 
As mentioned, tuples are immutable, so you cannot assign values to the elements 
after the tuple has been initialized. 


Mathematical Operators 


The usual mathematical operators work in Sage. So, +, —, and * all work as you 
would expect. As noted above / performs division, but if the operands are integers it 
promotes them to rational numbers. The % operator performs modular reduction a 
% nis the remainder of a divided by n, for a and n integral data types. You can 
accomplish integral division as follows. If a is an integer, and you want the quotient 
and remainder after division by n,a.quo_rem(n) returns a tuple (q,r) where q 
is the quotient and r is the remainder. 

One of the major differences between Sage and Python is that the operator 
is not xor, as it is in Python. Rather, this means exponentiation. So a‘n is a 
raised to the nth power. Alternately, this can be performed with the ** operator as 
a**n. 


A 


Control Statements 


If-else statements are written as follows: 


if <boolean statement> 
<tab> <block of code> 
elif <boolean statement> 
<tab> <block of code> 
else: 
<tab> <block of code> 


Where <boolean statement> indicates a valid statement in Python that 
evaluates to a Boolean expression, and <block of code> indicates a multi-line 
block of Python code. It is important to note that with if statements (and also loop 
statements), the blocks of code must be indented, and the subsequent control state- 
ment must return to the original level of indentation. This is how the interpreter 
knows how to match if elif and else statements. In the if and elif statements, the 
Boolean expression must be followed by a semicolon. For else statements the semi- 
colon immediately follows the keyword else. For the Boolean statements the stan- 
dard operators of Boolean (and, or) are spelled out exactly as ‘and’ and ‘or’. Meaning 
for a number less than 0 and greater than 3 one writes: (x < 0) or (3 < x). For 
a number greater than 0 and less than 3 one writes: (0 < x) and (x < 3). 

The syntax for a for loop is as follows: 


for <variable> in <iteratable object>: 
<tab> <block of code> 


In Python <iteratable objects> are sequential objects like lists or tuples 
(there are some others as well, but lists and tuples are the main case.) For example 
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for A in foo: 
print A 


prints the list of the elements in the list £oo. Or 


for j in range(10): 
print j 


prints the integers from 1 to 10. 
The most common exception to using a list or a tuple as an iterable object is 
iterating through a list of integers using the xrange function. For example: 


for j in xrange(len(foo) ): 
print ‘j=’, j, fool[j] 


prints a list of the indices and the elements at that index in the array. 

The xrange function allows loops to iterate through the integers [0, 1, 
---, (len(£o00)-1)] without instantiating the list as the function range would. 
The function xrange takes the parameters are the same as the range function does, 
the only difference is the output. 

While loops have the syntax: 


while <boolean expression> 
<tab> <block of code> 


For example: 


while ( x < 1): 
y=ruytrtx 
x = x/2 


With both while and for loops, the break keyword cause execution of the loop 
to stop, and continue causes control to begin executing at the next iteration of the 
loop. 


Functions 
Creating functions is very easy: 
def <function-name>(< comma separated list of parame- 


ters>): 
<tab> <block of code> 


Just like control statements, the body of the function must be delimited by in- 
dentation. The return statement specifies the value of the function to return. If 
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the function does not have a return statement, or the end of the body of the func- 
tion is reached without hitting a return statement, then the function returns the 
value None. For example, the following function: 


def f1(x, y): 
if -(O-S=-xX 3 2): 
Z=x*2 +x+1 
else: 
Z= xX-y 
return y 


For more information on Python programming, see http://www.Python.org/. At this time 
Sage uses Python 2.x, and not Python 3.0 or higher. This is not likely to change, but as the 
differences in the language are significant, if the examples here are not working, it may 
be worth checking out if the underlying version of Python that Sage uses has changed. 
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2.1 Implement Sage functions that perform affine cipher encryption/decryption, 
given a key that consists of a pair of integers a, b, bothin {1, 2,.. , 25} with a not 
divisible by 2 or 13. The functions should work on strings, and leave any non- 
alphabetic characters unchanged. Show the operation of your functions on an 
example. See problem 2.1 in Chapter 2 for a definition of an affine cipher. 

2.2 This question is to implement some functions useful to performing classical 
cipher attacks. 

a. Implement a Sage function that performs frequency attacks on a mono- 
alphabetic substitution ciphers. This function should take a ciphertext string, 
compute a histogram of the incidence of each letter (ignoring all non alpha- 
bet characters), and return a list of pairs (letter, incidence percentage) 
sorted by incidence percentage. 

b. Implement a Sage function that takes a partial mono-alphabetic substitution 
and a ciphertext and returns a potential plaintext. The partial mono-alpha- 
betic substitution should be specified as follows: As a 26 character string 
where the character at position i is the substitution of ith character of the 
alphabet, OR an underscore ‘_’ if the corresponding substitution is unknown. 
The potential plaintext should be the ciphertext with values specified by 
the mono-alphabetic substitution replaced by the lower-case plaintext. If the 
corresponding character is unknown (i.e. ‘_’ in the monoalphabetic substitu- 
tion cipher) print the cipher text as an uppercase character.) 

c. Use your functions from (a) and (b) to decrypt the following ciphertext: 
“ztmn pxtne cfa pegef kecnp cjt tmn zcwsenp ontmjsw ztnws tf wsvp 
xtfwvfefw, c feb fcwvtf, xtfxevgea vf gvoenwk, cfa aeavxcwea wt wse 
rntrtpvwvtf wscw cgg lef cne xnecwea eymcg.” 

2.3 Implement Sage functions to perform encryption/decryption with 2 x 2 Hill 
Cipher. The key should be an invertible Sage matrix over the integers mod 26. 
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Do not just call the built in Sage functionality for the Hill cipher. Show the 
operation of your functions on a plaintext of your choice. 
2.4 Implement a Sage function to perform encryption/decryption with anm X m Hill 
Cipher. The key should be an invertible Sage matrix over the integers mod 26. Do 
not just call the built in Sage functionality for the Hill cipher. Show the operation 
of your function on the functions you write on a plaintext of your choice. You may 
use any functions you wrote for the previous question to answer this question. 
This question is to implement and use a known plaintext attack on the Hill 
cipher. You may use functions from examples or previous questions, but do not 
use the built in Sage functions for the Hill Cipher. [Hint: The built in functions 
for MatrixSpace and FreeModule objects may be useful, but if they are too 
confusing to use, do not get caught up on them.] 
a. Implement a known plaintext attack on the hill cipher. 
b. Use the function that you wrote in part (a) to attack the following plaintext/ 
ciphertext pairs: 
plaintext = "friday" ciphertext = "izrvey" 
plaintext = "diamondisinstatue" ciphertext = "zisxlhdiwdingthyqq" 
plaintext = "thesecretdietistofuhotdogs" ciphertext = "qbayzelwilksscipqps 
vkafvssyy" 


N 
mn 


C.4 CHAPTER 3: BLOCK CIPHERS AND THE DATA 


ENCRYPTION STANDARD 


3.1 This problem references the Sage implementation from Appendix B.3 Example 1. 
a. Copy the diagram of the function fx of the Simplified DES Encryption details 
(Figure G.3 in Appendix G) and label each wire with the corresponding vari- 

able name from the Sage code that implements SDES Encryption. 

b. Copy the diagram of the Simplified DES Encryption Key Generation 
(Figure G.2) and label each wire with the corresponding variable names 
from the Sage code that implements the SDES Key Generation. 

3.2 a. Let temp_block denote a Sage variable that contains the output of the first 
application of function fx (fx in the Sage example code) while encrypting 
with Simplified DES. Using subroutines from the example Sage code, write 
Sage code to recover the input block passed to Simplified DES Decrypt. 
That is, reverse the first steps in Simplified DES Encrypt. You may assume 
that you have the first round key in a variable K1. 

b. Using subroutines from the Sage example code for Simplified DES, write a 
function to compute Simplified DES Decrypt. 

3.3 a. Consider EP, the expansion permutation. Find an inverse contraction 
permutation. That is, find a function that takes 8 bits down to 4 and inverts 
EP. Note that these are not unique. Implement this function EPinv as in the 
example Sage code. 

b. Take the function f_K from the example Sage code and modify it so that 
instead of calling the SBoxes, it calls EPinv after the round key is XORed 
in. Rename the modified function f_K_NoSBox. 

c. Modify the functions SDESEncrypt [see example Sage code], and SDES- 
Decrypt (see question 3.1] so that they then call f_K_NoSBox (from 
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part b). Call the new functions SDESEncryptNoSBox and SDESDe- 
cryptNoSBox. 

d. Do these new functions function as Encrypt/Decrypt functions of each 
other? (i.e. will SDESDecryptNoSBox give you back the input of SDES- 
EncryptNoSBox, given that they are using the same key)? 

e. Does SDESEncryptNoSBox make a good Encryption function, why or why 
not? Hint: Can you mount a known or chosen plaintext attack on the func- 
tions you wrote in part (d)? 


C.5 CHAPTER 4: BASIC CONCEPTS IN NUMBER THEORY AND 


4.1 


4.4 


FINITE FIELDS 


In the examples functions for the Euclidean and extended Euclidean GCD, 

the first input must be greater than the second. Furthermore, each argument 

must be a positive integer. Implement these functions such that these assump- 

tions need not be made about the input. Also for the extended Euclidean 

GCD, if the gcd of a and b is 1, return a inverse mod b and b inverse mod a 

(Your Sage functions may call the example Sage functions, or you may write 

these implementations from scratch. Do not merely call the built in Sage func- 

tionality.) Show your functions work on a few inputs. 

Suppose that polynomials are represented by lists of coefficients, where the 

coefficient at index i is the coefficient of x’. Using this representation, write 

Sage functions that perform the following polynomial operations (don’t just 

call the underlying Sage functions): 

a. Scalar multiply, given a scalar c, and a polynomial f, computes c ° f. 

. Addition, given two polynomials f, g,computes h = f + g. 

. Subtraction, given two polynomials f, g computes h = f — g. 

. Multiplication, given two polynomials f, g computes h = f*g. 

. For each of the above functions that you wrote show the output of the func- 
tion on 1 set of inputs. 

Either using the functions you wrote in the preceding question or the built in 

polynomial arithmetic in Sage, as well as, either the given polynomial extend- 

ed gcd, or the built in Sage extended gcd, implement a four function calculator 

for GF(24) with modulus x* + x + 1. Consider elements of GF(2*) to be 

degree 4 (fixed precision) polynomials in the primitive element, i.e., GF(2*), 

elements are represented by lists of 4 binary values. You may use the underly- 

ing polynomial functions in Sage, or any functions you wrote for the previous 

questions. 

a. addition 

b. scalar multiplication 

c. multiplication 

d. inversion 

This question asks about using the Sage functionality for computing in Finite 

Fields. 

a. Use Sage to create a finite field with 17 elements. In this field calculate: 

The difference: 13 — 16 


a — ce 


? 
nn 


° 
aN 
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The sum: 11 + 10 

The quotient:1/2 

The product: 3*8 

The multiplicative inverse of: 5 

b. Use Sage to create a finite field with 32 elements. Let 'a' denote the primi- 

tive element. In this field Calculate: 

The difference: (a‘2 + a) — (a + 1) 

The multiplicative inverse of: a“4 + a+ 1 
The quotient (a2 + 1)/(a“4 + a + 1) 

c. Use Sage to create a finite field with 53 elements. Let 'alpha' denote the 
primitive element. In this field Calculate: 

The sum: (3*alpha’2 + 4*alpha) — (alpha’2 + 3) 
The multiplicative inverse of: (alpha + 1) 
The product: (alpha + 2)*(alpha + 3) 

d. Use Sage to create a finite field with 503,777,509 elements. In this field 
calculate: 

The quotient: 123,456,789/456,555,333 
The multiplicative inverse of : 987,654,321 
The difference: 789,123,456 - 444,333,111 

This question is to use the built-in gcd functionality of Sage. 

a. Using the gcd functionality in Sage, compute the greatest common divisor of 
24 and 300 
4567 and 4731907 
100 and 1015 

b. Using the xgcd functionality in Sage, compute the extended greatest com- 
mon divisor 
36 and 624 
4321 and 9226177 
45 and 12345 

. Find two numbers, both greater than 100,000 that have a greatest common 

divisor of exactly 3. 

Show the output of Sage that verifies your answer is correct. 

The purpose of this question is to show familiarity with the Sage polynomial 

arithmetic functionality. 

a. Use Sage to initialize a polynomial ring over the field with two elements. 
Let f = x‘2+1 and g = x3 + x‘2+x+1. Compute f + g,f*g, the 
quotient and remainder of g divided by f, and the greatest common divisor 
of f and g. 

b. Use Sage to initialize a polynomial ring over the field with 31 elements. Let 
f = x‘5 + 17*x + 13 and g = x3 + 10*x’2 + 24*x + 3. Compute f — g, 
f*g, the quotient and remainder of dividing f by g, and the greatest common 
divisor of f and g. 

c. Use the GF(...) function to initialize a finite field with 16 elements, and 
suppose that a is the generator of this field. Then initialize a polynomial ring 
over this field. Compute the quotient and remainder of dividing 
(a3 + a + 1)x“4 + a*x’2 + (a2 + a)*x + (a + 1) by (a)x’2 + 
(aos + 1)*x + a2 
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d. 


In Sage initialize a degree 3 extension of the finite field with 5 elements 
with defining polynomial x“3 + x + 4. Further suppose that ’theta’ is the 
primitive element of this field. Compute 1/theta. 


C.6 CHAPTER 5: ADVANCED ENCRYPTION STANDARD 


5.1 The purpose of this question is to become more familiar with the algorithm for 
generating the Simplified AES S-Box. Each part of this problem is to write 
one part of the algorithm in Sage, and in the last part put them all together. 
The construction closely follows the description of the algorithm specification 
in the text. 


a. 


Consider the positive integers between 0 and 15 (inclusive) as 4 bit strings, 
so that 3 is 1100 (this ordering is known as little endian.) Define the map- 
ping from {0, 1, 2,..., 15} to GF(2*) by mapping the element with bit string 
by b; b> b; to the element by + b,a + b,a” + b3a° of GF(2*). The following 
snippet of Sage code sets F to the finite field with two elements L the finite 
field with 16 elements (extension of F with modulus a* + a + 1) and prim- 
itive element a (we use a here because a is a special value in Sage.) And V is 
the vector space of dimension 4 over F (you can think of this as 4 bit strings 
with addition defined on them.) 


F = GF(2); 
L.<a> = GF(2%4); 
V = L.vector_space(); 


As in the example code for Simplified AES we can map a bit list b to the 
corresponding element of L by L(V(b)). Write a Sage function that maps a 
positive integer in {0, 1,2,..., 15} to an element of L. (Hint: If x is a Sage 
Integer, z.bits() is a little-endian list of the bits of z, however z only has as 
many elements as the bit length of z. So, for example if z is 0, this function 
returns an empty list. However, L(V(b)) only works if b is a bit list of length 
4. You will have to work around this.) 


. Use the function from part (a) to write a Sage function to initialize a 2 dimen- 


sional array (either a list of lists or a matrix over L) so that the element at 
position (r, c) is the element of GF(2*) mapped to by 4r + c. 


. Write a function that takes M, a 2-dimensional array of elements in 


L = GF(2") (either a list of lists or a matrix over L) and maps each nonze- 
ro element to its inverse and 0 to 0. That is, your function should return M', 
the 2-dimensional array of elements in L where the element at row r and 
column c of M' is the inverse of M,, (or 0 if M,, = 0). (Hint: If z is a nonze- 
ro element of L, in Sage, z(—1) is the multiplicative inverse of z. If z is zero, 
this will raise an error.) 


. Write a function that takes a 2-dimensional array of elements in 


L = GF(2*) and for each element converts it to an element of V and 
applies the Linear transformation in step 4 of the S-Box generation 
algorithm. Then returns the resulting 2-dimensional array. The Sage code to 
initialize A and b would be: 
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A = Matrix(F, [ 
{ 1, 0, i ae 


b= Vv([1, 0, 0, 1)); 


And the linear equation is A*v + b. Then take the resulting element of V 
and map it back to an element of L (if v is an element of V, then L(v) is the 
corresponding element of L.) (Hint: If z is an element of L and v = z.vec- 
tor(), the linear transformation as is defined in the algorithm expects that 
the bits of v are reverse of how Sage orders them. To deal with this, you will 
either have to reverse the bits of v, or appropriately modify the A matrix.) 

e. Use the functions you just wrote to write a function that initializes the SBox 
matrix for simplified DES. Check your answer versus the SBoxes of the 
simplified AES function in the book. 

5.2 In the previous question we computed the SBox for Simplified DES. There are 
multiple ways to compute the inverse SBox. You can find each element of L in 
the SBox and figure out which element maps to it. Or you can reverse each of 
the steps in the previous algorithm. Write a Sage function to calculate the 
inverse SBox matrix. 

5.3 The algorithm for computing the Simplified AES SBox table does exactly that, 
it computes a table. However, this algorithm shows us how we can compute the 
SBox directly, without doing a table look up. Write a Sage function to compute 
the Simplified AES SBox and Inverse SBox directly. Meaning, write functions 
that take elements of L and return the element of L that the SBox table (or 
Inverse SBox) lookup would map to. (This is more than a textbook exercise. 
Some people consider the AES SBox lookups to be insecure because they can 
leak information through the cache. Such vulnerabilities are called Side Chan- 
nels. Computing SBoxes without lookups is one way to mitigate this type of 
attack. Although there is a conditional statement in this SBox computation, 
which could be exploited by a side channel attack.) 


C.7 CHAPTER 6: PEUDORANDOM NUMBER GENERATION 


AND STREAM CIPHERS 


6.1 (With regard to the code for this exercise, see www.pearsonhighered.com/ 
stallings) Breaking Blum Blum Shub is provably (polynomial time) equivalent 
to factoring. While this question does not prove this, it does show how to create 
a Sage function that gives considerable evidence for this fact. Specifically, we 
will show that given a function that gives you the previous Blum Blum Shub 
state from a Blum Blum Shub state, that we can write a probabilistic program 
that factors. The following function will break Blum Blum Shub (for small N): 


def previous_BBS_state(state): 

TT moma 

This function returns the previous Blum- 
BlumShub state. 
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a. 


Note that this is a toy function and will only 
work on small N. 


nun 


N = state[0]; 
R = IntegerModRing(N) ; 
X = R(state[1]); 


if (mot X.is_square()): 
print "Not a valid Blum-Blum-Shub RNG 
state." 
return None 


return [N, X.sqrt().lift()]; 


The first part of the problem is to notice that if you have integers x, y such 
that x # +y (mod N) and (x? — y’) = 0 mod N, then the usual difference 
of squares equation gives that (x” — y’) = (x — y)(x + y). And so we can 
hope that gcd (x — y, N) or ged (x + y, N) yield a nontrivial factor of N. 
Write a Sage function that takes x,y such that x4+ty (mod N) and 
(x? — y’?) = 0 mod N and tries to find a nontrivial factor of N. 


. Using the function you wrote in part (a) and the supplied function previ- 


ous_BBS_state, write a function that takes a number N (that is a product of 
two primes p, g both congruent to 3 mod 4) and returns the factors p and q. 
[Hint: you have to create your own BBS state, so you will have to choose your 
square. How do you choose a square such that you know you have x, y?] 


6.2 Write a Sage function that takes 3 successive outputs from a linear congruen- 
tial RNG, as well as the modulus m of the internal state, that returns a and c 
OR indicates that it cannot find these values. Generate a linear congruential 
state, and 3 successive outputs and show your function working. 

6.3 The purpose of this function is to become more familiar with the ANSI X9.17 
PRNG. For this problem you may use any solutions to other problems, or 
example code. 


a. 


Implement a function for a variant of the ANSI X9.17 PRNG using the sim- 
plified DES block encrypt, instead of two key triple-DES. Your function 
should take the current state (the seed, V, and the date/time, DT, variables 
as 8 bit long bit lists) as well as the SDES key as a 10 bit long bit list. Note 
that because this function uses SDES, instead of two key triple DES, you do 
not need two keys. 


. Implement a function for ANSI X9.17 PRNG using the simplified AES 


block encrypt. Your function should take the current state (the seed, V, and 
the date/time, DT, variables as 16 bit long bit lists) as well as a key as 16 bit 
long bit lists. Note that because this function uses SAES, instead of two key 
triple DES, you do not need two keys. 


C.8 CHAPTER 8: NUMBER THEORY 


8.1 Write a Sage function to implement Euler’s Totient function [Hint: You may 
find the Sage “factor” function useful here. ] 


8.2 


io) 
5 
Ge 


8.4 
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Note that the sample code for the Miller Rabin test returns True if the test 
finds, conclusively, that n is composite, otherwise the function returns False to 
indicate that the function did not find anything conclusively. As noted in this 
book, we can decide with high probability if m is prime or composite if we run 
this test multiple times. This exercise is to implement a version of the Miller 
Rabin test that does so. 
a. Implement a function that performs the “witness procedure” of Miller 
Rabin, that is, the code that checks whether or not an integer in 
{1,2,..., — 1} has the specified properties. 


b. Use the function that you wrote for part (a) to implement a function that 
takes a positive integer n( > 2), and a list of integers in {1,2,...,m — 1} 
and performs the “witness procedure” on each one. If any one of these de- 
termines that a is composite, then return False (to indicate a is composite) 
otherwise return True, to indicate that (with high probability) n is prime. 


Previously we saw that factoring can be reduced to breaking Blum Blum 

Shub’s security. In this problem we will see the other direction, namely that 

Blum Blum Shub’s security can be broken by factoring. For this problem you 

may use the fact that finding a square root mod a prime is a solved problem. In 

fact if p = 3 (mod 4) and x is a square mod p then the square root of x is given 
by x?*)4 mod p. Either use this formula or the built in Sage functionality to 
compute square roots in a prime field to write a function that takes a Blum 

Blum Shub internal state, and the two prime factors p, g (both 3 mod 4) of the 

modulus, and outputs a list of at most 4 possibilities for the previous Blum 

Blum Shub State. Generate a Blum Blum Shub state (with your own p, q) and 

show that your function works. [Hint: use the CRT] 

Sage has acommand "time" that works similar to "print." Specifically "time <expr>" 

runs the expression <expr> and displays some timing information. This exercise is to 

use this time command to try some experiments timing modular exponentiation with 

different parameters. For varying values of m and n (positive integers) generate a 

prime p at most 2”, and a random positive integer a less than p, then time calculating 

ModExp (a, e, p), for e = 2” and 2” — 1. (See Appendix B.7 Example 3.) For 

each different value of e run the experiment several times. Try this with at least two 

different values for (m, ). Be sure to try varying the sizes of these parameters drasti- 
cally (i.e. on the order of 10s and 100s.) What do you notice? What does this tell you? 

[Hint: If you do the experiment correctly, you should make an observation that forms 

the basis for side channel attacks, a powerful type of attack on crypto systems. | 

The purpose of this question is to show how to generalize the Square and Mul- 

tiply Exponentiation method to different radixes besides 2. This approach to 

modular exponentiation is known as a “fixed window” exponentiation. 

a. Write a Sage function that, given an integer x, a modulus N, and a base b, 
computes a list of length b, where the ith element of the list is x’ mod N. You 
may use the ModExp function or any other method to compute the expo- 
nentiation (but you don’t have to.) (See Appendix B.7 Example 3.) 

b. Write a Sage function that takes an integer x, an exponent e,a base b, anda 
modulus N. This function should compute a power table using the function 
you wrote in part (a) and then use it by using the base b expansion of e to 
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determine where to index into the table. You may use modular exponentia- 
tion, but only to calculate y? mod N, for any integer y. 

c. Given that you use ModExp as a routine in the function you wrote in part (b) 
what can you conclude about the optimal base to use for modular 
exponentiation? 


8.6 Suppose we want to create a Random Number Generator with hardness based 


on the Discrete Log problem. In this problem we will investigate such an RNG 
and show that it has some weaknesses. First, suppose that we have primes P, QO 
such that P = 2° Q + 1. Now suppose that we have two points X and Y with 
multiplicative order Q mod P. This means that ¥2 = Y? = 1 mod P. Let s[i] 
denote the value of the internal state at time i. We generate the following 
values as follows: 

The intermediate data value: t[i] = s[i] 

The next internal state s[i + 1] = Xl mod P 

The output of the Generate function ofi] = Yl mod P 

The following diagram shows the flow of the RNG. 


mod P 7 


s[i + WAH > t[i] > Yi mod P—» oli] 


We will call this RNG the Dual DL RNG (for Dual Discrete Log Random 

Number Generator) For the following questions feel free to use Sage’s built in 

modular exponentiation functionality, the example function for modular expo- 

nentiation, or any functions from previous problems. 

a. Implement a Sage function that takes primes P, Q and integers X, Y of mul- 
tiplicative order Q mod P and generates a random initial internal state s (an 
integer reduced mod Q). Have this function return a list with entries 
[P,Q,X,Y,s]. 

b. Implement a Sage function that takes as a parameter a five element list cor- 
responding to the internal state initialized by the function you wrote for 
part (a). This function should generate a single block of output, and update 
the list parameter’s last element to correspond to the next RNG state. 

c. Suppose that we have P = 15116301544809716639, Q = 755815077240485 
8319, X = 10655637283854386401, Y = 5886823825742381258, and fur- 
thermore we know that X° = Y mod P, where e = 1534964830632783921. 
Find the positive integer f such that Y! = X mod P. [Hint: remember that 
XQ = 1 mod P. Find the positive integer f such that es f = 1 + k* Q.] 

d. Now, using the values for P, Q, X, Y from part (c), write a Sage function 
that, given one output of the generate function (from part (b)) and gives the 
output from the next call to the generate function. Use the functions you 
wrote in part (a) and (b) to show that your function works. [Hint: What hap- 
pens if you exponentiate the output of the generate function by the value 
you found in part (c)?] 

e. Write a version of the function that you wrote in part (b) that takes only P, 
Q, and X. Have it generate the value Y in a manner such that you know the 


8.7 
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positive integer f such Y‘ = X mod P. Your function should return a tuple 
(rngstate, f) where rngstate, is a valid rng state like the function from part 
(b) returns. 

f. Generalize your attack function from part (d) to work given a block of out- 
put, with the Y and f values you generated in part (e). 

g. How would you modify this RNG to overcome this problem? 


The example version of the Chinese Remainder Theorem has several ineffi- 
ciencies. Observe that in the Chinese Remainder Theorem the first step is to 
initialize the M array, where the value of M[i] is the product of all the moduli 
except modulii]. This is performed at the beginning of every function call, 
which is somewhat inefficient, because it could just be done once, for a single 
set of moduli. Furthermore, the output of this function is larger than it needs 
to be, indeed, it need be no larger than the product of all the moduli. In this 
question, do not merely call built in Sage functions. 
a. Write a function to pre-compute the M array, it should also compute the 
product of all the moduli. 
b. Write a version of the CRT function that takes the precomputed M array 
and a list of residues. Make sure that the output of this function is no larger 
than it needs to be. 


The purpose of this question is to become more familiar with the Chinese 
Remainder Theorem functionality in Sage. Use Sage to compute the following 
questions about the CRT. 
a. Find a number that reduces to 3 and 6 modulo 10 and 17, respectively 
b. Find a number that reduces to 17, 89, 77, 65, and 100 modulo 23, 199, 503, 
647, and 593, respectively 
c. Find a number that reduces to 98189, 78089, and 13418 mod 519787, 722299 
and 166169, respectively. 
d. Compute the CRT basis of the moduli 100, 501, 999. 
e. Find three numbers that reduce mod the moduli 49, 99, 1003, and 33191 to 
i) 1,2,3,4 
ii) 2,3,5,7 
iii) 101,99, 102, 98 
f. Use Sage to compute an integer that is relatively prime to 1 through 5 
modulo the first 5 primes, respectively. 


The purpose of this question is to become more familiar with the Sage func- 

tionality for modular exponentiation. Use Sage to compute: 

a. 123°456 mod 789 

b. 100797 mod 797 

ec. 1530 mod 1000 

d. 111/222 mod 987654321 

e. 1217/2833 mod 3836311 

f. Compute N, a product of two primes, both greater than 1,000,000 and then 
compute 


The purpose of this function is to show how to use the Euler totient function- 
ality built into Sage. Using the built-in functionality in Sage, compute the 
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Euler totient function on the following inputs: 


a. 


b 
Cc 
d. Find an exponent x and one or two integers such that raising to the x power 


781 


. 10245 


110 


mod 547689 results in 1. Find at least one integer such that modular 
exponentiation with x and this modulus does not result in 1. 


. Find an exponent x and one or two integers such that raising to the x 


power mod 999999 results in 1. Find at least one integer such that modu- 
lar exponentiation with x and this modulus does not result in 1. 


C.9 CHAPTER 9: PUBLIC-KEY CRYPTOGRAPHY AND RSA 


9.1 Use Sage to answer the following questions. Show all your Sage input/output: 


9.2 


9.4 


a. 


Suppose your RSA public key factors as p = 6569 and g = 8089, and the 
public exponent e is 11. Suppose you were sent the Ciphertext 28901722. 
Perform the RSA Decryption and recover the plaintext. 


. Suppose that you want to encrypt the number 449 and send it to someone 


with public key N = 37617577, and e = 529 


. Suppose that you forgot your public exponent, but you know that the prime 


factors of your key’s modulus are 1723 and 5381 and your private exponent 
is 223. Find the public exponent. 


. Use Sage to generate an RSA public/private key pair and perform an 


encryption and decryption. 


Use Sage to solve the following problems: In part (a)-(c) determine if the 
following signatures are good or bad: 


a. 


b 
c. 
d 


N = 13962799 and e = 3 value to sign = 821 and signature = 8674413 


. N = 34300129 and e = 61 value to sign = 2478 and signature = 27535246 


N = 5898461 and e = 23 value to sign = 419 and signature = 2607727 


. Suppose that you have an RSA modulus with prime factors p = 3181 and 


q = 2677 and the public exponent is 163. Calculate the signature of 521 and 
then verify it. 


The purpose of this question is to implement RSA encrypt and decrypt func- 
tions with Sage. 


. Implement an RSA key generation function. 

. Implement an RSA encrypt function. 

. Implement an RSA decrypt function. 

. Show that your functions work by simulating an RSA encrypt and decrypt 


with them. 


The purpose of this question is to implement Sage functions for creating and 
verifying RSA signatures. For these questions you may use any answers from 
previous questions. 


a. 


Implement a Sage function that takes an integer and an RSA private key 
and produces an RSA signature of it. 
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. Implement a Sage function that takes an RSA signature and a hash value 


and determines if the signature is valid. 


. Show your functions work by simulating a sign and verify. Show at least one 


sign and verify and also show an example that if the hash or signature are 
incorrect, your verify function correctly fails. (You may use the key genera- 
tion function from an earlier problem.) 


C.10 CHAPTER 10: OTHER PUBLIC-KEY CRYPTOSYSTEMS 


10.1 For all of the following questions related to Diffie-Hellman show all of your 
Sage input and output. 


a. 


a. 


Cc. 


d. 


3 The purpose of this question is to use Sage to explore how solving the discrete 


Suppose that you are Bob and you have agreed on the domain parameters 
p = 70849 and g = 2. Further suppose that Alice has sent the value 
X = 39674. Compute a secret value y and compute Y, and the shared secret. 


. Suppose that Alice and Bob have agreed on the domain parameters 


p = 6779 and g = 3, further suppose that Alice chooses the secret value 
x = 384 and Bob chooses the secret value y = 152. Perform a simulated 
key exchange as in the example. 


. Find a prime g and a prime p such that p = 2q + 1, find an element in the 


finite field with p elements that has multiplicative order q. Perform a simu- 
lated DH Secret Exchange as in the examples. 


Implement a Sage function that takes a bound and returns 4 elements: 
DP. q, g, and F. Satisfying: p and q are prime, such that p = 2*q + 1, gis an 
integer with multiplicative order q in the finite field with p elements, Fis a 
Sage field object with p elements. 


. Implement a Sage function that takes the output from your function in part 


(a) and returns the pair (X, x) where X = gx mod p and x is greater than 1 
and less than q. 

Implement a Sage function that takes a public value from the other party in 
the DH key exchange and the secret value and returns the shared secret. 
Show an example key exchange with your functions from parts (a) — (c). 


logarithm can break DH. In Sage, if a is an element of a finite field, and g gen- 
erates a, then if the order of the finite field is small enough a.log(g) will return 
the discrete log of g with respect to a. Use this functionality to solve the 
following problems. 


a. 
b. 


Suppose p = 499, g = 7,and X = 297. Find x such that X = gx. 
Suppose p = 863, g = 5, X = 543, and Y = 239. Find x and y such that 
X = gpxand Y = g’y. 


. Suppose p = 7589, g = 2, X = 6075 and Y = 1318. Find the shared secret 


value. 


Recall the Dual DL PRNG (Problem 8.6). There is an actual crypto algorithm, 
called the Dual EC DL PRNG, where instead of an element in a multiplicative 
group mod a prime and exponentiation, we consider a point on an elliptic curve 
over a prime order finite field and scalar multiplication (see NIST SP-800-90, 
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Recommendation for Random Number Generation Using Deterministic Ran- 
dom Bit Generators.) We need to define some auxiliary functions: 


e x(P): maps the x-coordinate of an elliptic curve point, P, to the integer the 
smallest positive integer that maps to x mod P. 


e LSB,,,(a): returns the least significant m bits of integer a. 

And we also denote the following values: 

° p:aprime, with n bits. 

e E:an elliptic curve over a finite field with p elements, given by equation 
y=axrt+axtb. 

e P:a point on E, with prime order q (for maximum security q should be 
roughly the same size as p.) 

e Q:a point in the cyclic subgroup of E generated by P. 


At the beginning of iteration i we have internal state s[i], and we define the 
following values: 


1. t[i] = s[i] 
. S[i + 1] = x(t[i] * P) 
. fi] = x(t{i]+Q) 
- off] = LSBs (fi) 
Here o[i] is the output of the ith iteration block, and s[i + 1] 


The following diagram shows the flow for generating one block of output with 
this Crypto Algorithm. 


x(t[i] °P) 
fo | 


sli + 1/664 > t[i] —>x(t[i] + Q)—»1[i] > LSB, _¢(r[i]) —> ofi] 


& WwW N 


The following problems outline a similar problem with this algorithm as the 

one described in Problem 8.6. 

a. Implement a Sage function to generate a single output block from this algo- 
rithm (Your function should take an internal state represented as a list with 
the following elements [E,P,Q,si], where E is a Sage Elliptic Curve object, P 
is a point on E, with prime order q, and Q is a point on E, generated by Q. 

b. Write a Sage function that takes an output of this PRNG (i.e., the x coordi- 
nate of a point with the top 8 bits truncated off) and returns the possible 
values for R = t[i]* Q that could have generated that output [Hint: try the 
is_x_coordinate function on Elliptic Curve objects.] 

c. Suppose you have E defined by y*2 = x3 + 2x + 4, P = (42,980956284 
88211854), Q = (6396452788131036613,9671497098832291002), and you 
know that the P has order q = 1227273995918533091 and also 
Q = 99689 * P. Write a Sage function that takes an output from one itera- 
tion of this function and returns a list of the possible next internal states. 


10.5 


10.6 


10.7 


10.8 
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d. Suppose you know that ofi] = 58246156843038996, and ofi + 1] = 
64511473570997445, use the fact that you have two subsequent outputs to 
determine the possible internal states that could have generated these two 
outputs. 


For all of the following questions show your Sage input/output. 

a. Compute the order of the curve defined by y* = x* + 7*x + 25 over the 
finite field with 47 elements. 

b. On the curve defined by y* + x*y = x? + x over GF(2°) compute the 
inverse of the point (1,1). 

c. On the curve defined by y? + y = x? + x’ + x + 1 over the finite field 
with 701 elements, find a generator and show its order. 

d. On the curve defined by y* = x* + 4187*x + 3814 over finite field of size 
6421 compute the sum of the points (3711,373) and (4376,2463). 

e. On the elliptic curve defined by y* = x* + 3361*x + 6370 over finite field 
of size 8461 compute 1001 times the point (1735, 3464). 

f. On the elliptic curve defined by y? = x? + 1800*x + 1357 over finite field 
of size 8191, let P1 = (1794, 1318) and P2 = (3514, 409), compute the sum of 
13 times P1 plus 28 times P2. 


In this problem, use the domain parameters. E is the elliptic curve defined by 

y’ = x° + 8871*x + 7063 over the finite field with order 70177. The generator 

point G = (49359,30149) has order 70393. Show your Sage input/output. 

a. Suppose you are Bob and Alice has sent the point (10117, 64081) compute 
an integer y the point Y and the shared secret. 

b. Suppose that Alice chooses the secret value x = 2532 and Bob chooses the 
secret value y = 15276. 

c. Perform a full simulated secret agreement between Alice and Bob. 


The purpose of this question is to implement Sage functions to perform 
ECDH. 
a. Write a function that takes a curve, and a base point on the curve and gen- 
erates the secret value x and the public value X as per ECDH. 
b. Write a function that takes a public value and a secret value and computes 
the shared secret. 
c. Assume that your domain parameters are: 
Elliptic Curve defined by y” = x? + 26484*x + 15456 over Finite Field of 
size 63709 
q = 63839 
G = (53819,6786) 
Show your functions work by simulating an ECDH key exchange. 
Recall that for cryptographic purposes, we use curves with prime order. The 
purpose of this question is to show why. Let E be the elliptic curve defined by 
y? = x? + 7489*x + 12591 over Finite Field of size 23431. This curve has 
order 23304. Let the base point be (20699, 19493). 
a. Compute 10 random multiples of this base point. What do you notice? 
b. Why is this bad? (Hint: What would happen if this was Alice or Bob’s public 
point?) 
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C.11 CHAPTER 11: CRYPTOGRAPHIC HASH FUNCTIONS 


11.1 The following describes a simple hash function: Choose p, g primes and com- 
pute N = pq. Choose g relatively prime to N and less than N. Then a number 
nis hashed as follows: 


H = g"modN 
If there is an m that hashes to the same value as n, then 
g” = g’mod N 
so 
g” "=1modN 
which implies that 


m — n = Omod A(N) 


So breaking this amounts to finding a multiple of é(N), which is the hard prob- 

lem in RSA. 

a. Write a function that takes a bitlength n and generates a modulus N of 
bitlength n and g less than N and relatively prime to it. 

b. Show the output of your function from part (a) for a few outputs. 
Using N, g, n as arguments write a function to perform the hashing. 

For parts (c) — (e) compute the simple hash: 

c. N = 600107, g = 154835, n = 239715 

d. N = 548155966307, g = 189830397891, n = 44344313866 

e. N = 604766153, g = 12075635,n = 443096843 

f. Write a function that creates a collision given p and q. Show that your func- 
tion works for a couple of examples. 


C.12 CHAPTER 13: DIGITAL SIGNATURES 


13.1 Use Sage to solve the following problems. For these questions assume that we 

are using DSA with domain parameters: 

P = 7,877,914,592,603,328,881 

q = 44449 

g = 2,860,021,798,868,462,661 

Use these domain parameters to determine if the signatures are valid in parts 

(a) - (). 

a. public key y = 3798043471854149631, hash value H = 59367, and signature 
(r,s) = (31019,4047) 

b. public key y = 1829820126190370021, hash value H = 77241, and signature 
(r,s) = (24646,43556) 

c. public key y = 4519088706115097514, hash value H = 48302, and signature 
(r,s) = (36283,32514) 

Perform a signing operation in parts (d)-(e). 


C.12 / DIGITAL SIGNATURES C-23 


d. private key x = 8146, hash value H = 22655 
e. private key x = 1548, hash value H = 32782 


13.2 The purpose of this question is to implement a DSA signature verification 
function. 
a. Implement a function that takes domain parameters p, q, and g. Also, a 
Hash value H (in {1,2,...,p — 1}),a public key y, and a signature (7,5). 
b. Use the function you wrote in part (a) as well as the functions from the 
DSA examples to simulate a DSA signature and verify as in the examples. 
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GLOSSARY 


In studying the Imperium, Arrakis, and the whole culture which produced Maud’Dib, many 
unfamiliar terms occur. To increase understanding is a laudable goal, hence the definitions and 
explanations given below. 

—Dnune, Frank Herbert 


Some of the terms in this glossary are from the Jnternet Security Glossary[RFC 2828]. 
These are indicated in the glossary by an asterisk. 


asymmetric encryption A form of cryptosystem in which encryption and decryption are 
performed using two different keys, one of which is referred to as the public key and one of 
which is referred to as the private key. Also known as public-key encryption. 


authentication* The process of verifying an identity claimed by or for a system entity. 


authenticator Additional information appended to a message to enable the receiver to 
verify that the message should be accepted as authentic. The authenticator may be 
functionally independent of the content of the message itself (e.g., a nonce or a source iden- 
tifier) or it may be a function of the message contents (e.g., a hash value or a cryptographic 
checksum). 


avalanche effect A characteristic of an encryption algorithm in which a small change in the 
plaintext or key gives rise to a large change in the ciphertext. For a hash code, the avalanche 
effect is a characteristic in which a small change in the message gives rise to a large change in 
the message digest. 


bacteria Program that consumes system resources by replicating itself. 


birthday attack This cryptanalytic attack attempts to find two values in the domain of a 
function that map to the same value in its range. 


block chaining A procedure used during symmetric block encryption that makes an output 
block dependent not only on the current plaintext input block and key, but also on earlier 
input and/or output. The effect of block chaining is that two instances of the same plaintext 
input block will produce different ciphertext blocks, making cryptanalysis more difficult. 


block cipher A symmetric encryption algorithm in which a block of plaintext bits (typical- 
ly 64 or 128) is transformed as a whole into a ciphertext block of the same length. 


byte A sequence of 8 bits. Also referred to as an octet. 


cipher An algorithm for encryption and decryption. A cipher replaces a piece of informa- 
tion (an element in plaintext) with another object with the intent to conceal meaning. 
Typically, the replacement rule is governed by a secret key. 


ciphertext The output of an encryption algorithm; the encrypted form of a message or data. 


code An unvarying rule for replacing a piece of information (e.g., letter, word, phrase) 
with another object not necessarily of the same sort. Generally, there is no intent to conceal 
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meaning. Examples include the ASCII character code (each character is represented 
by 7 bits) and frequency-shift keying (each binary value is represented by a particular 
frequency). 


computationally secure Secure because the time and/or cost of defeating the security are 
too high to be feasible. 


confusion A cryptographic technique that seeks to make the relationship between the sta- 
tistics of the ciphertext and the value of the encryption key as complex as possible. This is 
achieved by the use of a complex scrambling algorithm that depends on the key and the 
input. 


conventional encryption Symmetric encryption. 


covert channel A communications channel that enables the transfer of information in a 
way unintended by the designers of the communications facility. 


cryptanalysis The branch of cryptology dealing with the breaking of a cipher to recover 
information or forging encrypted information that will be accepted as authentic. 


cryptographic checksum An authenticator that is a cryptographic function of both the data 
to be authenticated and a secret key. Also referred to as a message authentication code 
(MAC). 


cryptography The branch of cryptology dealing with the design of algorithms for encryp- 
tion and decryption, intended to ensure the secrecy and/or authenticity of messages. 


cryptology The study of secure communications, which encompasses both cryptography 
and cryptanalysis. 


decryption The translation of encrypted text or data (called ciphertext) into original text 
or data (called plaintext). Also called deciphering. 


differential cryptanalysis A technique in which chosen plaintexts with particular XOR 
difference patterns are encrypted. The difference patterns of the resulting ciphertext provide 
information that can be used to determine the encryption key. 


diffusion A cryptographic technique that seeks to obscure the statistical structure of the 
plaintext by spreading out the influence of each individual plaintext digit over many cipher- 
text digits. 


digital signature An authentication mechanism that enables the creator of a message to 
attach a code that acts as a signature. The signature is formed by taking the hash of the mes- 
sage and encrypting the message with the creator’s private key. The signature guarantees the 
source and integrity of the message. 


digram A two-letter sequence. In English and other languages, the relative frequency of 
various digrams in plaintext can be used in the cryptanalysis of some ciphers. Also called 
digraph. 


discretionary access control* An access control service that enforces a security policy 
based on the identity of system entities and their authorizations to access system resources. 
This service is termed “discretionary” because an entity might have access rights that permit 
the entity, by its own volition, to enable another entity to access some resource. 
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divisor One integer is said to be a devisor of another integer if there is no remainder on 
division. 

encryption The conversion of plaintext or data into unintelligible form by means of a 
reversible translation, based on a translation table or algorithm. Also called enciphering. 


firewall A dedicated computer that interfaces with computers outside a network and has 
special security precautions built into it in order to protect sensitive files on computers with- 
in the network. It is used to service outside networks connections, especially the Internet and 
dial-in lines. 


greatest common divisor The greatest common divisor of two integers, a and 5, is the 
largest positive integer that divides both a and b. One integer is said to divide another inte- 
ger if there is no remainder on division. 


hash function A function that maps a variable-length data block or message into a fixed- 
length value called a hash code. The function is designed in such a way that, when protect- 
ed, it provides an authenticator to the data or message. Also referred to as a message 
digest. 


honeypot A decoy system designed to lure a potential attacker away from critical systems. 
A form of intrusion detection. 


initialization vector A random block of data that is used to begin the encryption of multi- 
ple blocks of plaintext, when a block-chaining encryption technique is used. The IV serves to 
foil known-plaintext attacks. 


intruder An individual who gains, or attempts to gain, unauthorized access to a computer 
system or to gain unauthorized privileges on that system. 


intrusion detection system A set of automated tools designed to detect unauthorized 
access to a host system. 


Kerberos The name given to Project Athena’s code authentication service. 


key distribution center A system that is authorized to transmit temporary session keys to 
principals. Each session key is transmitted in encrypted form using a master key that the key 
distribution center shares with the target principal. 


logic bomb Logic embedded in a computer program that checks for a certain set of condi- 
tions to be present on the system. When these conditions are met, it executes some function 
resulting in unauthorized actions. 


mandatory access control A means of restricting access to objects based on fixed security 
attributes assigned to users and to files and other objects. The controls are mandatory in the 
sense that they cannot be modified by users or their programs. 


man-in-the-middle attack A form of active wiretapping attack in which the attacker inter- 
cepts and selectively modifies communicated data in order to masquerade as one or more of 
the entities involved in a communication. 


master key A long-lasting key that is used between a key distribution center and a princi- 
pal for the purpose of encoding the transmission of session keys. Typically, the master keys 
are distributed by noncryptographic means. Also referred to as a key-encrypting key. 
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meet-in-the-middle attack This is a cryptanaltytic attack that attempts to find a value in 
each of the range and domain of the composition of two functions such that the forward map- 
ping of one through the first function is the same as the inverse image of the other through 
the second function—quite literally meeting in the middle of the composed function. 


message authentication A process used to verify the integrity of a message. 
message authentication code (MAC) Cryptographic checksum. 
message digest Hash function. 


modular arithmetic A kind of integer arithmetic that reduces all numbers to one of a fixed 
set [0,...,2 — 1] for some number n. Any integer outside this range is reduced to one in this 
range by taking the remainder after division by n. 


mode of operation A technique for enhancing the effect of a cryptographic algorithm or 
adapting the algorithm for an application, such as applying a block cipher to a sequence of 
data blocks or a data stream. 


multilevel security A capability that enforces access control across multiple levels of classi- 
fication of data. 


multiple encryption Repeated use of an encryption function with different keys to produce 
a more complex mapping from plaintext to ciphertext. 


nibble A sequence of four bits. 
nonce An identifier or number that is used only once. 


one-way function A function that is easily computed, but the calculation of its inverse is 
infeasible. 


password* A secret data value, usually a character string, that is used as authentication 
information. A password is usually matched with a user identifier that is explicitly presented 
in the authentication process, but in some cases, the identity may be implicit. 


plaintext The input to an encryption function or the output of a decryption function. 


primitive root If rand nv are relatively prime integers with n > 0 and if d(n) is the least 
positive exponent m such that r” = 1 mod n, then r is called a primitive root modulo n. 


private key One of the two keys used in an asymmetric encryption system. For secure com- 
munication, the private key should only be known to its creator. 


pseudorandom number generator A function that deterministically produces a sequence 
of numbers that are apparently statistically random. 


public key One of the two keys used in an asymmetric encryption system. The public key is 
made public and is to be used in conjunction with a corresponding private key. 


public-key certificate Consists of a public key plus a User ID of the key owner with the 
whole block signed by a trusted third party. Typically, the third party is a certificate authority 
(CA) that is trusted by the user community, such as a government agency or a financial 
institution. 


public-key encryption Asymmetric encryption. 
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public-key infrastructure (PKI) The set of hardware, software, people, policies, and proce- 
dures needed to create, manage, store, distribute, and revoke digital certificates based on 
asymmetric cryptography. 


relatively prime Two numbers are relatively prime if they have no prime factors in com- 
mon; that is, their only common divisor is 1. 


replay attacks An attack in which a service already authorized and completed is forged by 
another “duplicate request” in an attempt to repeat authorized commands. 


residue When the integer a is divided by the integer n, the remainder r is referred to as the 
residue. Equivalently, r = a mod n. 


residue class All the integers that have the same remainder when divided by n form a 
residue class (mod n). Thus, for a given remainder r, the residue class (mod n) to which it 
belongs consists of the integers r,7 + n,r + 2n,.... 


RSA algorithm A public-key encryption algorithm based on exponentiation in modular 
arithmetic. It is the only algorithm generally accepted as practical and secure for public-key 
encryption. 


secret key The key used in a symmetric encryption system. Both participants must share 
the same key, and this key must remain secret to protect the communication. 


security attack* An assault on system security that derives from an intelligent threat; that 
is, an intelligent act that is a deliberate attempt (especially in the sense of a method or tech- 
nique) to evade security services and violate the security policy of a system. 


security mechanism A process (or a device incorporating such a process) that is designed 
to detect, prevent, or recover from a security attack. 


security service A processing or communication service that enhances the security of the 
data processing systems and the information transfers of an organization. The services are 
intended to counter security attacks, and they make use of one or more security mechanisms 
to provide the service. 


security threat* A potential for violation of security, which exists when there is a circum- 
stance, capability, action, or event that could breach security and cause harm. That is, a threat 
is a possible danger that might exploit a vulnerability. 


session key A temporary encryption key used between two principals. 


steganography Methods of hiding the existence of a message or other data. This is different 
than cryptography, which hides the meaning of a message but does not hide the message 
itself. 


stream cipher A symmetric encryption algorithm in which ciphertext output is produced 
bit-by-bit or byte-by-byte from a stream of plaintext input. 


symmetric encryption A form of cryptosystem in which encryption and decryption are per- 
formed using the same key. Also known as conventional encryption. 


trapdoor Secret undocumented entry point into a program used to grant access without 
normal methods of access authentication. 
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trapdoor one-way function A function that is easily computed, and the calculation of its 
inverse is infeasible unless certain privileged information is known. 


Trojan horse* A computer program that appears to have a useful function, but also has a 
hidden and potentially malicious function that evades security mechanisms, sometimes by 
exploiting legitimate authorizations of a system entity that invokes the program. 


trusted system A computer and operating system that can be verified to implement a given 
security policy. 


unconditionally secure Secure even against an opponent with unlimited time and unlimit- 
ed computing resources. 


virtual private network Consists of a set of computers that interconnect by means of a 
relatively unsecure network and that make use of encryption and special protocols to pro- 
vide security. 


virus Code embedded within a program that causes a copy of itself to be inserted in one or 
more other programs. In addition to propagation, the virus usually performs some unwanted 
function. 


worm Program that can replicate itself and send copies from computer to computer across 
network connections. Upon arrival, the worm may be activated to replicate and propagate 
again. In addition to propagation, the worm usually performs some unwanted function. 


zombie A program that secretly takes over another Internet-attached computer and then 
uses that computer to launch attacks that are difficult to trace to the zombie’s creator. 


ACRONYMS 


3DES 
AES 
AH 
ANSI 
CBC 
CC 
CESG 


CFB 
CMAC 


CRT 
DDoS 
DES 
DoS 
DSA 
DSS 
ECB 
ESP 
FIPS 


IAB 
IETF 
IP 
IPsec 
ISO 


ITU 
ITU-T 


IV 


Triple Data Encryption Standard 

Advanced Encryption Standard 

Authentication Header 

American National Standards Institute 

Cipher Block Chaining 

Common Criteria 

Communications-Electronics Security 
Group 

Cipher Feedback 

Cipher-Based Message Authentication 
Code 

Chinese Remainder Theorem 

Distributed Denial of Service 

Data Encryption Standard 

Denial of Service 

Digital Signature Algorithm 

Digital Signature Standard 

Electronic Codebook 

Encapsulating Security Payload 

Federal Information Processing 
Standard 

Internet Architecture Board 

Internet Engineering Task Force 

Internet Protocol 

IP Security 

International Organization for 
Standardization 

International Telecommunication Union 

ITU Telecommunication 
Standardization Sector 

Initialization Vector 


KDC 
LAN 
MAC 
MIC 
MIME 
MDS5 
MTU 
NIST 


NSA 
OFB 
PCBC 
PGP 
PKI 
PRNG 
RFC 
RNG 
RSA 
SET 
SHA 
SHS 
S/MIME 
SNMP 


SNMPv3 


SSL 
TCP 
TLS 
UDP 
WAN 


Key Distribution Center 

Local Area Network 

Message Authentication Code 

Message Integrity Code 

Multipurpose Internet Mail Extension 

Message Digest, Version 5 

Maximum Transmission Unit 

National Institute of Standards 

and Technology 

National Security Agency 

Output Feedback 

Propagating Cipher Block Chaining 

Pretty Good Privacy 

Public Key Infrastructure 

Pseudorandom Number Generator 

Request for Comments 

Random Number Generator 

Rivest-Shamir-Adelman 

Secure Electronic Transaction 

Secure Hash Algorithm 

Secure Hash Standard 

Secure MIME 

Simple Network Management 
Protocol 

Simple Network Management Protocol 
Version 3 

Secure Sockets Layer 

Transmission Control Protocol 

Transport Layer Security 

User Datagram Protocol 

Wide Area Network 


